functional call named notation clashes with SQL feature
in [PgSql]
|
From: Pavel Stehule on 27 May 2010 03:16 2010/5/27 Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com>: > On 27/05/10 09:50, Pavel Stehule wrote: >> >> 2010/5/27 Heikki Linnakangas<heikki.linnakangas(a)enterprisedb.com>: >>> >>> AFAIU, the standard doesn't say anything about named parameters. Oracle >>> uses >>> =>, but as you said, that's ambiguous with the =>  operator. >>> >>> +1 for FOR. >> >> I don't see any advantage of "FOR". > > Any advantage over AS? It doesn't clash with the "foo AS bar" syntax that > the standard is using for something completely different, as Peter pointed > out in the original post. No, standard knows "AS" in different context. In param list standard doesn't use keyword "AS". > >> We can change ir to support new  standard or don't change it. > > What new standard? > ANSI SQL 2011 Pavel > -- >  Heikki Linnakangas >  EnterpriseDB  http://www.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
From: Pavel Stehule on 27 May 2010 03:17 2010/5/27 Abhijit Menon-Sen <ams(a)toroid.org>: > At 2010-05-27 08:50:18 +0200, pavel.stehule(a)gmail.com wrote: >> >> I don't see any advantage of "FOR". We can change ir to support new >> standard or don't change it. > > Adopting FOR would mean we don't use AS in a way that conflicts with the > standard. That's its only advantage. But I agree with you, I don't think > it's worth inventing a new non-standard wart for this case. current using "AS" isn't in conflict with standard .. look to standard, please. Pavel > > I don't really like the idea of getting rid of => as an operator either; > I'm torn between staying true to the standard and politely looking the > other way as Tom suggested we might end up doing. > > -- ams > -- 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: Heikki Linnakangas on 27 May 2010 03:40 On 27/05/10 10:16, Pavel Stehule wrote: > 2010/5/27 Heikki Linnakangas<heikki.linnakangas(a)enterprisedb.com>: >> On 27/05/10 09:50, Pavel Stehule wrote: >>> >>> 2010/5/27 Heikki Linnakangas<heikki.linnakangas(a)enterprisedb.com>: >>>> >>>> AFAIU, the standard doesn't say anything about named parameters. Oracle >>>> uses >>>> =>, but as you said, that's ambiguous with the => operator. >>>> >>>> +1 for FOR. >>> >>> I don't see any advantage of "FOR". >> >> Any advantage over AS? It doesn't clash with the "foo AS bar" syntax that >> the standard is using for something completely different, as Peter pointed >> out in the original post. > > No, standard knows "AS" in different context. In param list standard > doesn't use keyword "AS". As Peter pointed out in the original post, according to the standard "function(foo AS bar)" means something else than what we have now. Please re-read the original post. >>> We can change ir to support new standard or don't change it. >> >> What new standard? > > ANSI SQL 2011 Oh, does that have something to say about named parameters? Is the draft publicly available somewhere? -- Heikki Linnakangas EnterpriseDB http://www.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
From: Heikki Linnakangas on 27 May 2010 03:51 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 => ? -- Heikki Linnakangas EnterpriseDB http://www.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
From: Pavel Stehule on 27 May 2010 04:29
2010/5/26 Peter Eisentraut <peter_e(a)gmx.net>: > It turns out that the SQL standard uses the function call notation > > foo(this AS that) > > for something else: > > <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> > > <generalized expression> ::= <value expression> AS <path-resolved > user-defined type name> > > In systems that have inheritance of composite types, this is used to > specify which type the value is supposed to be interpreted as (for > example, to treat the value as a supertype). > can it be used (in ANSI SQL semantic) as cast? like SELECT foo(10.33 AS int) > Seems kind of bad to overload this with something completely different. > What should we do? > > Is ANSI SQL consistent in this syntax? SQL/XML use "AS" in different meaning. Regards Pavel > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |