functional call named notation clashes with SQL feature
in [PgSql]
|
From: Pavel Stehule on 27 May 2010 02:50 2010/5/27 Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com>: > 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. > I don't see any advantage of "FOR". We can change ir to support new standard or don't change it. 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 > -- 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 02:54 2010/5/27 Tom Lane <tgl(a)sss.pgh.pa.us>: > Robert Haas <robertmhaas(a)gmail.com> writes: >> On Wed, May 26, 2010 at 8:21 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >>> 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.) > >> I suppose the most painful thing about doing that is that it would >> break hstore. Â Are there other commonly-used modules that rely on => >> as an operator name? > > There don't seem to be any other contrib modules that define => as an > operator name, but I'm not sure what's out there on pgfoundry or > elsewhere. Â The bigger issue to me is not so much hstore itself as that > this is an awfully attractive operator name for anything container-ish. > Wasn't the JSON-datatype proposal using => for an operator at one stage? > (The current wiki page for it doesn't seem to reflect any such idea, > though.) Â And I think I remember Oleg & Teodor proposing such an > operator in conjunction with some GIN-related idea or other. > >> In spite of the difficulties, I'm reluctant to give up on it. Â I >> always thought that the "AS" syntax was a crock and I'm not eager to >> invent another crock to replace it. Â Being compatible with the SQL >> standard and with Oracle is not to be taken lightly. > > Yeah, I know. Â Though this could end up being one of the bits of the > spec that we politely decline to follow, like upper-casing identifiers. > Still, it's a good idea to think again before we've set the release > in stone ... we have a last minutes for decision. any other change will need years - like 'standard strings'. I agree so it's not good time for change. But this change is a few lines in parser. Regards Pavel > > Â Â Â Â Â Â Â Â Â Â Â Â 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 > -- 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 02:55 2010/5/27 Robert Haas <robertmhaas(a)gmail.com>: > On Wed, May 26, 2010 at 9:28 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> Robert Haas <robertmhaas(a)gmail.com> writes: >>> On Wed, May 26, 2010 at 8:21 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >>>> 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.) >> >>> I suppose the most painful thing about doing that is that it would >>> break hstore. Â Are there other commonly-used modules that rely on => >>> as an operator name? >> >> There don't seem to be any other contrib modules that define => as an >> operator name, but I'm not sure what's out there on pgfoundry or >> elsewhere. Â The bigger issue to me is not so much hstore itself as that >> this is an awfully attractive operator name for anything container-ish. >> Wasn't the JSON-datatype proposal using => for an operator at one stage? >> (The current wiki page for it doesn't seem to reflect any such idea, >> though.) Â And I think I remember Oleg & Teodor proposing such an >> operator in conjunction with some GIN-related idea or other. >> >>> In spite of the difficulties, I'm reluctant to give up on it. Â I >>> always thought that the "AS" syntax was a crock and I'm not eager to >>> invent another crock to replace it. Â Being compatible with the SQL >>> standard and with Oracle is not to be taken lightly. >> >> Yeah, I know. Â Though this could end up being one of the bits of the >> spec that we politely decline to follow, like upper-casing identifiers. >> Still, it's a good idea to think again before we've set the release >> in stone ... > > Perhaps one idea would be to: > > 1. Invent a new crock for now. > 2. Add a duplicate version of the hstore => operator with a different name. > 3. Emit a warning whenever an operator called => is created. > 4. Document that beginning in PG 9.1, we will no longer support => as > an operator name. +1 Pavel > > That's still going to cause a fair amount of pain, but certainly less > if we decide it now rather than later. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise Postgres Company > > -- > 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
From: Heikki Linnakangas on 27 May 2010 03:12 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. > We can change ir to support new standard or don't change it. What new standard? -- 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: Abhijit Menon-Sen on 27 May 2010 03:15
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. 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 |