functional call named notation clashes with SQL feature
in [PgSql]
|
From: Andrew Dunstan on 26 May 2010 18:52 Peter Eisentraut wrote: > 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). > > Seems kind of bad to overload this with something completely different. > What should we do? > > 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); IIRC the standard's mechanism for this is 'paramname => value', but I think that has problems because of our possibly use of => as an operator - otherwise that would be by far the best way to go. cheers andrew -- 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: alvherre on 26 May 2010 19:09 Excerpts from Andrew Dunstan's message of mié may 26 18:52:33 -0400 2010: > 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); IIRC the standard's > mechanism for this is 'paramname => value', but I think that has > problems because of our possibly use of => as an operator - otherwise > that would be by far the best way to go. I think we were refraining from => because the standard didn't specify this back then -- AFAIU this was introduced very recently. But now that it does, and that the syntax we're implementing conflicts with a different feature, it seems wise to use the standard-mandated syntax. The problem with the => operator seems best resolved as not accepting such an operator in a function parameter, which sucks but we don't seem to have a choice. Perhaps we could allow "=>" to resolve as the operator for the case the user really needs to use it; or a schema-qualified operator. -- Álvaro Herrera <alvherre(a)commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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: "David E. Wheeler" on 26 May 2010 19:34 On May 26, 2010, at 4:09 PM, alvherre wrote: > The problem with the => operator seems best resolved as not accepting > such an operator in a function parameter, which sucks but we don't seem > to have a choice. Perhaps we could allow "=>" to resolve as the > operator for the case the user really needs to use it; or a > schema-qualified operator. I think requiring schema-qualification is an acceptable compromise. Best, David -- 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 26 May 2010 19:39 On 27/05/10 02:09, alvherre wrote: > Excerpts from Andrew Dunstan's message of mié may 26 18:52:33 -0400 2010: > >> 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); IIRC the standard's >> mechanism for this is 'paramname => value', but I think that has >> problems because of our possibly use of => as an operator - otherwise >> that would be by far the best way to go. > > I think we were refraining from => because the standard didn't specify > this back then -- AFAIU this was introduced very recently. But now that > it does, and that the syntax we're implementing conflicts with a > different feature, it seems wise to use the standard-mandated syntax. > > The problem with the => operator seems best resolved as not accepting > such an operator in a function parameter, which sucks but we don't seem > to have a choice. Perhaps we could allow "=>" to resolve as the > operator for the case the user really needs to use it; or a > schema-qualified operator. 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. -- 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: Tom Lane on 26 May 2010 20:21
alvherre <alvherre(a)commandprompt.com> writes: > The problem with the => operator seems best resolved as not accepting > such an operator in a function parameter, which sucks but we don't seem > to have a choice. "Sucks" is not the word; "utterly unacceptable" is the word. Having an expression mean different things depending on context is a recipe for unbelievable nightmares. Can you imagine dealing with that in a query generator for example? Or even ruleutils.c? If we go with the spec's syntax I think we'd have no realistic choice except to forbid => altogether as an operator name. (And no, I'm not for that.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |