On Wed, May 26, 2010 at 9:28 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Wed, May 26, 2010 at 8:21 PM, Tom Lane <t...@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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers