From: Robert Haas on 26 May 2010 20:57 On Wed, May 26, 2010 at 8:21 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > 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.) 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? 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. -- 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
From: Heikki Linnakangas on 26 May 2010 21:06 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? As evidence to the contrary: http://archives.postgresql.org/pgsql-hackers/2009-08/msg00558.php -- 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 21:28 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 ... 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
From: Robert Haas on 26 May 2010 21:38 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. 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
From: Pavel Stehule on 27 May 2010 02:48
>> > > 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. > What is advice of "FOR" instead "AS"? it is exactly same. Regards Pavel > 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 > -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |