Re: BUG #5136: Please drop the string literal syntax for CREATE FUNCTION ...
От | Pavel Stehule |
---|---|
Тема | Re: BUG #5136: Please drop the string literal syntax for CREATE FUNCTION ... |
Дата | |
Msg-id | 162867790910252143u79dc4f46y53fe43d2b497b919@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #5136: Please drop the string literal syntax for CREATE FUNCTION ... (Timothy Madden <terminatorul@gmail.com>) |
Список | 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 по дате отправления:
Следующее
От: Pavel StehuleДата:
Сообщение: Re: BUG #5136: Please drop the string literal syntax for CREATE FUNCTION ...