2009/10/25 Timothy Madden <terminato...@gmail.com>:
>
> On Sun, Oct 25, 2009 at 6:17 PM, Pavel Stehule <pavel.steh...@gmail.com>
> wrote:
>>
>> 2009/10/25 Timothy Madden <terminato...@gmail.com>:
>> >
>> >
>> > On Sun, Oct 25, 2009 at 12:42 PM, Peter Eisentraut <pete...@gmx.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
>
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
