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

From Robert Haas
Subject Re: functional call named notation clashes with SQL feature
Date
Msg-id AANLkTikPEPpjy1zCVzCLEdjK8e0x36L9TSJPbzQ81Nuc@mail.gmail.com
Whole thread Raw
In response to Re: functional call named notation clashes with SQL feature  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Thu, Jun 3, 2010 at 11:34 AM, Bruce Momjian <bruce@momjian.us> 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.

I don't mind supporting := and => as much as I mind supporting only
:=, and I think that's the other reasonable alternative.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Keepalive for max_standby_delay
Next
From: Robert Haas
Date:
Subject: Re: How to pass around collation information