BUG #5136: Please drop the string literal syntax for CREATE FUNCTION ...

[Timothy Madden]

The following bug has been logged online:

Bug reference:      5136
Logged by:          Timothy Madden
Email address:      terminatorul@...
PostgreSQL version: 8.4.1
Operating system:   Ubuntu
Description:        Please drop the string literal syntax for CREATE
FUNCTION ...
Details:

Can the string literal syntax for CREATE FUNCTION please, please be dropped
... ?

http://www.postgresql.org/docs/8.4/interactive/plpgsql-structure.html

It is not ANSI/ISO and so annoying for compatibility.

Thank you,
Timothy Madden

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[Peter Eisentraut-2]

On lör, 2009-10-24 at 14:01 +0000, Timothy Madden wrote:
> Can the string literal syntax for CREATE FUNCTION please, please be dropped
> ... ?
>
> http://www.postgresql.org/docs/8.4/interactive/plpgsql-structure.html
>
> It is not ANSI/ISO and so annoying for compatibility.

Whatever is inside the string literal is also not ANSI/ISO, so why would
it make a difference?


--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[Timothy Madden]

On Sun, Oct 25, 2009 at 12:42 PM, Peter Eisentraut <peter_e@...> wrote:

On lör, 2009-10-24 at 14:01 +0000, Timothy Madden wrote:
> Can the string literal syntax for CREATE FUNCTION please, please be dropped
> ... ?

[...]

> It is not ANSI/ISO and so annoying for compatibility.

Whatever is inside the string literal is also not ANSI/ISO, so why would
it make a difference?

At least the function declaration syntax would be right. I think it would be an important difference; this string literal idea is so strange and unnatural ...

And why the function body would not be standard ? Do you mean it can never be for some reason ? How about a simple function ?

Thank you,
Timothy Madden

[Pavel Stehule]

2009/10/25 Timothy Madden <terminatorul@...>:

>
>
> On Sun, Oct 25, 2009 at 12:42 PM, Peter Eisentraut <peter_e@...> wrote:
>>
>> On lör, 2009-10-24 at 14:01 +0000, Timothy Madden wrote:
>> > Can the string literal syntax for CREATE FUNCTION please, please be
>> > dropped
>> > ... ?
>
> [...]
>>
>> > It is not ANSI/ISO and so annoying for compatibility.
>>
>> Whatever is inside the string literal is also not ANSI/ISO, so why would
>> it make a difference?
>>
> At least the function declaration syntax would be right. I think it would be
> an important difference; this string literal idea is so strange and
> unnatural ...
>
> And why the function body would not be standard ?

Because standard knows only SQL/PSM language for SQL procedures.
Others databases support only one language for sql procedures (PL/SQL,
T-SQL). But PostgreSQL supports plpgsql, plperl, plpython as sql
procedures - and I am sure, so standard doesnt calculate with
multilangual environments.

Regards
Pavel Stehule

Do you mean it can never
> be for some reason ? How about a simple function ?
>
> Thank you,
> Timothy Madden
>

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[Timothy Madden]

On Sun, Oct 25, 2009 at 6:17 PM, Pavel Stehule <pavel.stehule@...> wrote:

2009/10/25 Timothy Madden <terminatorul@...>:

>
>
> On Sun, Oct 25, 2009 at 12:42 PM, Peter Eisentraut <peter_e@...> wrote:
>>
>> On lör, 2009-10-24 at 14:01 +0000, Timothy Madden wrote:
>> > Can the string literal syntax for CREATE FUNCTION please, please be
>> > dropped
>> > ... ?
>
> [...]
>>
>> > It is not ANSI/ISO and so annoying for compatibility.
>>
>> Whatever is inside the string literal is also not ANSI/ISO, so why would
>> it make a difference?
>>
> At least the function declaration syntax would be right. I think it would be
> an important difference; this string literal idea is so strange and
> unnatural ...
>
> And why the function body would not be standard ?

Because standard knows only SQL/PSM language for SQL procedures.
Others databases support only one language for sql procedures (PL/SQL,
T-SQL). But PostgreSQL supports plpgsql, plperl, plpython as sql
procedures - and I am sure, so standard doesnt calculate with
multilangual environments.

Ok I get it. So Posgres also offers perl and python in addition to SQL.
But at least for SQL, which is included and defined in the standard, could
the syntax be made conforming ? As an alternative to the one already
used (to offer the additional langauges) ?

So that the additional languages are provided as before, and the
standard-definded one still follows the standard ?


Thank you,
Timothy Madden


P.S. :
As a note, actually the standard provides for other languages, with the
procedures only referenced as external (pre-compiled) instead of
defined/scripted in line.

If anyone is interested you have below the CREATE FUNCTION and
CREATE PROCEDURE syntax definition from SQL-3
 (SQL-99, Part 2 - Foundation).

<SQL-invoked procedure> ::=
         PROCEDURE <schema qualified routine name>  <SQL parameter declaration list>
        <routine characteristics>
        <routine body>

<SQL-invoked function> ::=
        { <function specification> | <method specification designator> }
         <routine body>

<function specification> ::=
        FUNCTION <schema qualified routine name> <SQL parameter declaration list>
        <returns clause>
        <routine characteristics>
      [ <dispatch clause> ]

<routine characteristic> ::=
         <language clause>
       | <parameter style clause>
       | SPECIFIC <specific name>
       | <deterministic characteristic>
       | <SQL-data access indication>
       | <null-call clause>
       | <transform group specification>
       | <dynamic result sets characteristic>

<routine body> ::=
        <SQL routine body>
      | <external body reference>

<SQL routine body> ::= <SQL procedure statement>

<external body reference> ::=
       EXTERNAL [ NAME <external routine name> ]
          [ <parameter style clause> ]
          [ <external security clause> ]

<language clause> ::=
          LANGUAGE <language name>

<language name> ::=
          ADA | C | COBOL | FORTRAN | MUMPS | PASCAL | PLI | SQL

<dynamic result sets characteristic> ::=
          DYNAMIC RESULT SETS <maximum dynamic result sets>

<parameter style clause> ::=
         PARAMETER STYLE <parameter style>

<dispatch clause> ::= STATIC DISPATCH
<returns clause> ::= RETURNS <returns data type> [ <result cast> ]
<result cast> ::= CAST FROM <result cast from type>

<result cast from type> ::=
          <data type> [ <locator indication> ]

<returns data type> ::= <data type> [ <locator indication> ]

<parameter style> ::=
         SQL
       | GENERAL

<deterministic characteristic> ::=
       DETERMINISTIC
     | NOT DETERMINISTIC

<SQL-data access indication> ::=
        NO SQL
      | CONTAINS SQL
      | READS SQL DATA
      | MODIFIES SQL DATA

[Tom Lane-2]

Timothy Madden <terminatorul@...> writes:
> Ok I get it. So Posgres also offers perl and python in addition to SQL.
> But at least for SQL, which is included and defined in the standard, could
> the syntax be made conforming ?

I think you still haven't got the point: there is *no* function language
that we offer that exactly matches what the spec has got.  Not using
string-literal syntax, difficult as that is already, would probably
represent about 1% of the work needed to implement what the spec
suggests.

                        regards, tom lane

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[Timothy Madden]

On Mon, Oct 26, 2009 at 12:13 AM, Tom Lane <tgl@...> wrote:

Timothy Madden <terminatorul@...> writes:
> Ok I get it. So Posgres also offers perl and python in addition to SQL.
> But at least for SQL, which is included and defined in the standard, could
> the syntax be made conforming ?

I think you still haven't got the point: there is *no* function language
that we offer that exactly matches what the spec has got.  Not using
string-literal syntax, difficult as that is already, would probably
represent about 1% of the work needed to implement what the spec
suggests.

I would like to put to good use the statements and expression that do match
(SELECT/INSERT/UPDATE/ ...), and the very function declaration syntax is
getting in the way, making even those matches now useless ...

Thank you,
Timothy Madden

[Pavel Stehule]

2009/10/25 Timothy Madden <terminatorul@...>:

>
> On Sun, Oct 25, 2009 at 6:17 PM, Pavel Stehule <pavel.stehule@...>
> wrote:
>>
>> 2009/10/25 Timothy Madden <terminatorul@...>:
>> >
>> >
>> > On Sun, Oct 25, 2009 at 12:42 PM, Peter Eisentraut <peter_e@...>
>> > wrote:
>> >>
>> >> On lör, 2009-10-24 at 14:01 +0000, Timothy Madden wrote:
>> >> > Can the string literal syntax for CREATE FUNCTION please, please be
>> >> > dropped
>> >> > ... ?
>> >
>> > [...]
>> >>
>> >> > It is not ANSI/ISO and so annoying for compatibility.
>> >>
>> >> Whatever is inside the string literal is also not ANSI/ISO, so why
>> >> would
>> >> it make a difference?
>> >>
>> > At least the function declaration syntax would be right. I think it
>> > would be
>> > an important difference; this string literal idea is so strange and
>> > unnatural ...
>> >
>> > And why the function body would not be standard ?
>>
>> Because standard knows only SQL/PSM language for SQL procedures.
>> Others databases support only one language for sql procedures (PL/SQL,
>> T-SQL). But PostgreSQL supports plpgsql, plperl, plpython as sql
>> procedures - and I am sure, so standard doesnt calculate with
>> multilangual environments.
>
>
> Ok I get it. So Posgres also offers perl and python in addition to SQL.
> But at least for SQL, which is included and defined in the standard, could
> the syntax be made conforming ? As an alternative to the one already
> used (to offer the additional langauges) ?
>

look on plsqlpsm - it is implementation of SQL/PSM.

> So that the additional languages are provided as before, and the
> standard-definded one still follows the standard ?
>
>
> Thank you,
> Timothy Madden
>
>
> P.S. :
> As a note, actually the standard provides for other languages, with the
> procedures only referenced as external (pre-compiled) instead of
> defined/scripted in line.

this is external languages. It is different.

>
> If anyone is interested you have below the CREATE FUNCTION and
> CREATE PROCEDURE syntax definition from SQL-3
>  (SQL-99, Part 2 - Foundation).
>
> <SQL-invoked procedure> ::=
>          PROCEDURE <schema qualified routine name>  <SQL parameter
> declaration list>
>         <routine characteristics>
>         <routine body>
>
> <SQL-invoked function> ::=
>         { <function specification> | <method specification designator> }
>          <routine body>
>
> <function specification> ::=
>         FUNCTION <schema qualified routine name> <SQL parameter declaration
> list>
>         <returns clause>
>         <routine characteristics>
>       [ <dispatch clause> ]
>
> <routine characteristic> ::=
>          <language clause>
>        | <parameter style clause>
>        | SPECIFIC <specific name>
>        | <deterministic characteristic>
>        | <SQL-data access indication>
>        | <null-call clause>
>        | <transform group specification>
>        | <dynamic result sets characteristic>
>
> <routine body> ::=
>         <SQL routine body>
>       | <external body reference>
>
> <SQL routine body> ::= <SQL procedure statement>
>
> <external body reference> ::=
>        EXTERNAL [ NAME <external routine name> ]
>           [ <parameter style clause> ]
>           [ <external security clause> ]
>
> <language clause> ::=
>           LANGUAGE <language name>
>
> <language name> ::=
>           ADA | C | COBOL | FORTRAN | MUMPS | PASCAL | PLI | SQL
>
> <dynamic result sets characteristic> ::=
>           DYNAMIC RESULT SETS <maximum dynamic result sets>
>
> <parameter style clause> ::=
>          PARAMETER STYLE <parameter style>
>
> <dispatch clause> ::= STATIC DISPATCH
> <returns clause> ::= RETURNS <returns data type> [ <result cast> ]
> <result cast> ::= CAST FROM <result cast from type>
>
> <result cast from type> ::=
>           <data type> [ <locator indication> ]
>
> <returns data type> ::= <data type> [ <locator indication> ]
>
> <parameter style> ::=
>          SQL
>        | GENERAL
>
> <deterministic characteristic> ::=
>        DETERMINISTIC
>      | NOT DETERMINISTIC
>
> <SQL-data access indication> ::=
>         NO SQL
>       | CONTAINS SQL
>       | READS SQL DATA
>       | MODIFIES SQL DATA
>

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[Pavel Stehule]

2009/10/25 Timothy Madden <terminatorul@...>:

>
>
> On Mon, Oct 26, 2009 at 12:13 AM, Tom Lane <tgl@...> wrote:
>>
>> Timothy Madden <terminatorul@...> writes:
>> > Ok I get it. So Posgres also offers perl and python in addition to SQL.
>> > But at least for SQL, which is included and defined in the standard,
>> > could
>> > the syntax be made conforming ?
>>
>> I think you still haven't got the point: there is *no* function language
>> that we offer that exactly matches what the spec has got.  Not using
>> string-literal syntax, difficult as that is already, would probably
>> represent about 1% of the work needed to implement what the spec
>> suggests.
>
>
> I would like to put to good use the statements and expression that do match
> (SELECT/INSERT/UPDATE/ ...), and the very function declaration syntax is
> getting in the way, making even those matches now useless ...

???

Pavel
>
> Thank you,
> Timothy Madden
>

--
Sent via pgsql-bugs mailing list (pgsql-bugs@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

[Timothy Madden]

On Mon, Oct 26, 2009 at 6:44 AM, Pavel Stehule <pavel.stehule@...> wrote:

2009/10/25 Timothy Madden <terminatorul@...>:

>
[...]
> I would like to put to good use the statements and expression that do match
> (SELECT/INSERT/UPDATE/ ...), and the very function declaration syntax is
> getting in the way, making even those matches now useless ...

???

It is a way of saying I see this as the first 1% to be done towards SQL/PSM, so I
can then use the other statements in a function.

Thank you,
Timothy Madden