Re: BUG #5136: Please drop the string literal syntax for CREATE FUNCTION ... - Mailing list pgsql-bugs

From Pavel Stehule
Subject Re: BUG #5136: Please drop the string literal syntax for CREATE FUNCTION ...
Date
Msg-id 162867790910252143u79dc4f46y53fe43d2b497b919@mail.gmail.com
Whole thread Raw
In response to Re: BUG #5136: Please drop the string literal syntax for CREATE FUNCTION ...  (Timothy Madden <terminatorul@gmail.com>)
List pgsql-bugs
2009/10/25 Timothy Madden <terminatorul@gmail.com>:
>
> On Sun, Oct 25, 2009 at 6:17 PM, Pavel Stehule <pavel.stehule@gmail.com>
> wrote:
>>
>> 2009/10/25 Timothy Madden <terminatorul@gmail.com>:
>> >
>> >
>> > On Sun, Oct 25, 2009 at 12:42 PM, Peter Eisentraut <peter_e@gmx.net>
>> > wrote:
>> >>
>> >> On l=C3=B6r, 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=C2=A0standard ?
>
>
> 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
> =C2=A0(SQL-99, Part 2 - Foundation).
>
> <SQL-invoked procedure> ::=3D
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 PROCEDURE <schema qualif=
ied routine name>=C2=A0 <SQL parameter
> declaration list>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <routine characteristics>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <routine body>
>
> <SQL-invoked function> ::=3D
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 { <function specification> | <=
method specification designator> }
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <routine body>
>
> <function specification> ::=3D
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FUNCTION <schema qualified rou=
tine name> <SQL parameter declaration
> list>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <returns clause>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <routine characteristics>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [ <dispatch clause> ]
>
> <routine characteristic> ::=3D
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <language clause>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | <parameter style clause>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | SPECIFIC <specific name>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | <deterministic characteristic>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | <SQL-data access indication>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | <null-call clause>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | <transform group specification>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | <dynamic result sets characteristi=
c>
>
> <routine body> ::=3D
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <SQL routine body>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | <external body reference>
>
> <SQL routine body> ::=3D <SQL procedure statement>
>
> <external body reference> ::=3D
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 EXTERNAL [ NAME <external routine na=
me> ]
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [ <parameter style=
 clause> ]
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [ <external securi=
ty clause> ]
>
> <language clause> ::=3D
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LANGUAGE <language=
 name>
>
> <language name> ::=3D
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ADA | C | COBOL | =
FORTRAN | MUMPS | PASCAL | PLI | SQL
>
> <dynamic result sets characteristic> ::=3D
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DYNAMIC RESULT SET=
S <maximum dynamic result sets>
>
> <parameter style clause> ::=3D
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 PARAMETER STYLE <paramet=
er style>
>
> <dispatch clause> ::=3D STATIC DISPATCH
> <returns clause> ::=3D RETURNS <returns data type> [ <result cast> ]
> <result cast> ::=3D CAST FROM <result cast from type>
>
> <result cast from type> ::=3D
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <data type> [ <loc=
ator indication> ]
>
> <returns data type> ::=3D <data type> [ <locator indication> ]
>
> <parameter style> ::=3D
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SQL
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | GENERAL
>
> <deterministic characteristic> ::=3D
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DETERMINISTIC
> =C2=A0=C2=A0=C2=A0=C2=A0 | NOT DETERMINISTIC
>
> <SQL-data access indication> ::=3D
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NO SQL
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | CONTAINS SQL
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | READS SQL DATA
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | MODIFIES SQL DATA
>

pgsql-bugs by date:

Previous
From: Karen Pease
Date:
Subject: Re: Postmaster hangs
Next
From: Pavel Stehule
Date:
Subject: Re: BUG #5136: Please drop the string literal syntax for CREATE FUNCTION ...