2010/5/27 Robert Haas <robertmh...@gmail.com>: > 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.
+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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
