functional call named notation clashes with SQLfeature
in [PgSql]
|
From: Peter Eisentraut on 27 May 2010 03:49 On tor, 2010-05-27 at 04:06 +0300, Heikki Linnakangas wrote: > On 27/05/10 03:57, Robert Haas wrote: > > Being compatible with the SQL > > standard and with Oracle is not to be taken lightly. > > I seem to be alone believing that the SQL standard doesn't say anything > about named function parameters. Can someone point me to the relevant > section of the standard? It will be in SQL:2011. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Peter Eisentraut on 27 May 2010 04:15 On tor, 2010-05-27 at 10:51 +0300, Heikki Linnakangas wrote: > On 27/05/10 10:49, Peter Eisentraut wrote: > > On tor, 2010-05-27 at 04:06 +0300, Heikki Linnakangas wrote: > >> On 27/05/10 03:57, Robert Haas wrote: > >>> Being compatible with the SQL > >>> standard and with Oracle is not to be taken lightly. > >> > >> I seem to be alone believing that the SQL standard doesn't say anything > >> about named function parameters. Can someone point me to the relevant > >> section of the standard? > > > > It will be in SQL:2011. > > Does it mandate => ? <routine invocation> ::= <routine name> <SQL argument list> <routine name> ::= [ <schema name> <period> ] <qualified identifier> <SQL argument list> ::= <left paren> [ <SQL argument> [ { <comma> <SQL argument> }... ] ] <right paren> <SQL argument> ::= <value expression> | <generalized expression> | <target specification> | <contextually typed value specification> | <named argument specification> <generalized expression> ::= <value expression> AS <path-resolved user-defined type name> <named argument specification> ::= <SQL parameter name> <named argument assignment token> <named argument SQL argument> <named argument SQL argument> ::= <value expression> | <target specification> | <contextually typed value specification> <named argument assignment token> ::= => -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Peter Eisentraut on 27 May 2010 15:37 On tor, 2010-05-27 at 12:59 -0400, Tom Lane wrote: > > I think we should fix it now. Quick thought: maybe we could use > FOR > > instead of AS: select myfunc(7 for a, 6 for b); > > I'm afraid FOR doesn't work either; it'll create a conflict with the > spec-defined SUBSTRING(x FOR y) syntax. How about select myfunc(a := 7, b := 6); ? -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Stephen Frost on 27 May 2010 15:59 * Tom Lane (tgl(a)sss.pgh.pa.us) wrote: > Peter Eisentraut <peter_e(a)gmx.net> writes: > > select myfunc(a := 7, b := 6); Kinda like it myself. > Question #1: is the SQL committee likely to standardize that out > from under us, too? Couldn't say on that one. > Question #2: will ecpg have a problem with this? Or psql for that > matter (can you have a psql variable named '=')? psql doesn't like it, for what it's worth: postgres=# \set = hi \set: error Thanks, Stephen
From: Bruce Momjian on 28 May 2010 12:39
Josh Berkus wrote: > Since former SQL Server / Sybase apps are the most likely to use named > parameter notation in PostgreSQL, having a syntax which could be ported > using only "sed" would be nice. > > Relevant to the whole discussion, though ... is the conflicting SQL > standard syntax something we're every likely to implement? Not sure, but I assume people could be using the AS syntax in other databases (for the inheritance usage) and then trying to use it in our database. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |