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

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Timothy Madden <terminatorul(at)gmail(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5136: Please drop the string literal syntax for CREATE FUNCTION ...
Date: 2009-10-26 04:43:14
Message-ID: 162867790910252143u79dc4f46y53fe43d2b497b919@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

2009/10/25 Timothy Madden <terminatorul(at)gmail(dot)com>:
>
> On Sun, Oct 25, 2009 at 6:17 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
>>
>> 2009/10/25 Timothy Madden <terminatorul(at)gmail(dot)com>:
>> >
>> >
>> > On Sun, Oct 25, 2009 at 12:42 PM, Peter Eisentraut <peter_e(at)gmx(dot)net>
>> > 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
>

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Pavel Stehule 2009-10-26 04:44:21 Re: BUG #5136: Please drop the string literal syntax for CREATE FUNCTION ...
Previous Message Karen Pease 2009-10-26 03:47:27 Re: Postmaster hangs