On Mon, Oct 26, 2009 at 6:37 AM, Pavel Stehule <pavel.stehule@xxxxxxxxx> wrote:
2009/10/26 Tom Lane <tgl@xxxxxxxxxxxxx>:
it is not correct. When you would to use more statements, then you can> Alvaro Herrera <alvherre@xxxxxxxxxxxxxxxxx> 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.
>
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
Thank you all for your considerate replies.
Why am I wielding the wrong argument ? My argument is standards conformance.
Because there are many other non-standard expressions in the current syntax ?
So my issue is just one more on the list ...
Full SQL/PSM support seems pretty far; why is it needed in order to also consider
the non string-literal function definitions for language SQL functions ? I rather see
removing quotes as the first step towards SQL/PSM, then the last ...
We are getting philosophical, but agreement is still necessary for a patch from what
I know, especially that the effort to understand the project is comprehensive. That
is why I was concerned about agreement.
The DELIMITER artefact is also misplaced in my opinion; what is the use for it ?
The BEGIN ... END syntax is pretty clear ...
DELIMITER is just to keep the client-side parsing / input simple ?
For other languages the string literal syntax is ok, my issue only concerns
LANGUAGE SQL functions ....
Thank you,
Timothy Madden
