On Mon, Oct 26, 2009 at 6:37 AM, Pavel Stehule <pavel.steh...@gmail.com>wrote:
> 2009/10/26 Tom Lane <t...@sss.pgh.pa.us>:
> > Alvaro Herrera <alvhe...@commandprompt.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
>
>
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
