Re: functional call named notation clashes with SQL feature - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: functional call named notation clashes with SQL feature
Date
Msg-id 201006031544.o53FibW25806@momjian.us
Whole thread Raw
In response to Re: functional call named notation clashes with SQL feature  (Bruce Momjian <bruce@momjian.us>)
Responses Re: functional call named notation clashes with SQL feature  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <bruce@momjian.us> writes:
> > > Are we sure we want hstore compatibility to drive this decision?
> > 
> > hstore is what it is, and has been that way for a long time.  We can't
> > just ignore it.  And I don't think breaking it (and probably other code)
> > on zero notice is an acceptable outcome.
> 
> Well, it seems we are going to be stuck supporting => because it is hard
> to argue that the SQL standards committee should adopt := instead of =>
> because of hstore.  ;-)
> 
> I hate eventually having two documented ways of doing something, but it
> appears by releasing := we are doing exactly that.
> 
> Is telling hstore users they have to change => to something else such a
> large major version incompatibility that it is worth supporting and
> documenting two syntaxes for parameter assignment?  It is that calculus
> that has me questioning our approach.

Thinking some more, what is the value of keeping => in hstore for 9.0?
Perhaps we could create a script they could run on 8.4 that would add
support for the new hstore operator to replace =>, and then they can
upgrade to 9.0 when they are ready.  I see only three mentions of => in
hstore.sql.  Do we really want to keep the := baggage forever just for
hstore?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + None of us is going to be here forever. +


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: How to pass around collation information
Next
From: Dimitri Fontaine
Date:
Subject: Re: functional call named notation clashes with SQL feature