Re: Can the string literal syntax for function definitions please be dropped ?

2009/10/26 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> SQL/PSM is a different beast than all the rest of the PLs, because it is
>> standard, so I am sure that we will want to implement the standard
>> syntax (no string literal) when we have SQL/PSM.  But implementing no-
>> string-literals before we get full SQL/PSM support would be pointless,
>> because there are so many other things that are not standard in that
>> area.  Simply removing the quotes (which is what you are requesting)
>> would not take our standards compliance much further.
>
> [ after re-reading the spec a little bit ... ]
>
> One interesting point here is that I don't think the spec suggests
> that SQL/PSM can be written in-line in the CREATE FUNCTION statement
> at all.  What I see (at least in SQL99) is
>
>         <schema function> ::=
>              CREATE <SQL-invoked function>
>
>         <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 body> ::=
>                <SQL routine body>
>              | <external body reference>
>
>         <SQL routine body> ::= <SQL procedure statement>
>
> and <SQL procedure statement> seems to allow one (count em, one) SQL DDL
> or DML statement.  So per spec, essentially every interesting case
> requires an <external body reference>.  We could possibly support the
> single-SQL-statement case without any quotes --- at least, it doesn't
> obviously break clients to do that; handling it inside the backend still
> seems nontrivial.  But it's not clear to me that that case is useful
> enough to be worth the trouble.
>

it is not correct. When you would to use more statements, then you can
to use BEGIN ... END;

so CREATE FUNCTION foo(...)
RETURNS int AS
BEGIN
DECLARE x int;
SET x = 10;
RETURN x;
END;

is correct.

CREATE FUNCTION foo(...)
RETURNS int AS
RETURN x;

is correct too. The block is optional in SQL/PSM.

http://www.postgres.cz/index.php/SQL/PSM_Manual

What I known, other DBMS have to solve this complications too. Next
possibility is using some special symbol for ending parser like
DELIMITER.

Actually we have a independent parsers for SQL and PL languages. It
has some adventages:
a) we could to support more PL languages
b) PL parser are relative small, SQL parser is relative clean

If we integrate some language to main parser, then we have to able to
block some parts of parser dynamicky - because some functionality
should be invisible from some PL - SQL/PSM FOR statement has different
syntax than PL/pgSQL FOR statement. I thing, so this is possible - but
it uglify parser. If somebody found way how to do extendable parser in
bison, then we could to go far, but actually I don't advantages change
anything on current syntax.

Regards
Pavel Stehule

>                        regards, tom lane
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>