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

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) ?

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