functional call named notation clashes with SQL feature
in [PgSql]
|
From: Robert Haas on 31 May 2010 22:40 On Mon, May 31, 2010 at 9:24 PM, Florian Pflug <fgp(a)phlo.org> wrote: > On Jun 1, 2010, at 0:23 , Tom Lane wrote: >> "David E. Wheeler" <david(a)kineticode.com> writes: >>> On May 31, 2010, at 8:56 AM, Andrew Dunstan wrote: >>>> I don't have strong feelings about the timing - I'd be very surprised if := were to be used in this context for any other purpose, so I don't think we'd be biting ourselves too much by just using that now. But if we do that, we should deprecate use of => as an operator now, and definitely remove its use in hstore either now or in 9.1. >> >> My feeling is that (a) there is no hurry to do anything about an >> unreleased draft of the standard, and (b) perhaps Peter could lobby >> the committee to change the standard before it does get published. >> >> hstore's use of => is pretty well embedded already; waiting another >> release or two before breaking things is not going to make it >> significantly more painful. > > > There might be some value in providing an alternative operator though, even if there is no definitive plan to deprecate '=>'. > > hstore gained quite a few new features in 9.0 that might attract new users. If there is even a slight chance that '=>' will be deprecated during the next few releases, it'd be nice to save these users the hassle of migration... > > For text => text and text[] => text[] I'd propose '||>' as an alternative, since they both combine their arguments, kind of a like a concatenation. > For hstore => text[] I'd suggest '&>' since the result's set of keys is the intersection of both argument's key-sets. I was going to propose ==> across the board. -- 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: Tom Lane on 3 Jun 2010 11:28 Bruce Momjian <bruce(a)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. 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 3 Jun 2010 11:44 On Thu, Jun 3, 2010 at 11:34 AM, Bruce Momjian <bruce(a)momjian.us> wrote: > Tom Lane wrote: >> Bruce Momjian <bruce(a)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 -- 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: Dimitri Fontaine on 3 Jun 2010 11:53 Bruce Momjian <bruce(a)momjian.us> writes: > 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. Well it's not only hstore. Anyone can CREATE OPERATOR => on any released version of PostgreSQL currently. I don't think we can deprecate it on short notice, so we'll have := in 9.0, and maybe a deprecation notice for =>. Now that it's pretty clear from Peter that the standard is not going to change its choice here, I'll vote adding a WARNING each time an operator called => is created, so that we get a chance to move later on. Regards, -- dim -- 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 3 Jun 2010 11:54
Bruce Momjian <bruce(a)momjian.us> writes: > Thinking some more, what is the value of keeping => in hstore for 9.0? Backwards compatibility. You have not made any argument today that we have not been over many times before. I do not have time to argue about this today --- I have to go fix max_standby_delay. 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 |