functional call named notation clashes with SQL feature
in [PgSql]
|
From: "David E. Wheeler" on 3 Jun 2010 12:04 On Jun 3, 2010, at 8:54 AM, Tom Lane wrote: >> 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. I'm sure there's a lot of code using => in the wild. We can't just drop them without a deprecation cycle. Best, David -- 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: "David E. Wheeler" on 3 Jun 2010 12:05 On Jun 3, 2010, at 8:53 AM, Dimitri Fontaine wrote: > 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. Should support for ==> be added to hstore for 9.0? So both => and ==> will work? Best, David -- 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: Andrew Dunstan on 3 Jun 2010 23:09 Jan Wieck wrote: >> >> That is a sad wart that we should never have done, IMNSHO (it was >> before my time or I would have objected ;-) ). But beyond that, = is >> an operator in SQL and := is never an operator, IIRC. > > As far as I can tell, this was already in the code when Bruce moved it > into core as -r1.1 on my behalf (before I had commit privileges). I do > not recall if the = as alternative to := was my idea or not. But I'm > willing to take the blame for it because it dates back to a time where > convenience seemed important. > I forgive you ;=) If my worst sin were only this bad I'd be truly happy. cheers andrew -- 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: Jan Wieck on 3 Jun 2010 22:47 On 5/27/2010 11:52 PM, Andrew Dunstan wrote: > > Bruce Momjian wrote: >> Peter Eisentraut wrote: >> >>> On tor, 2010-05-27 at 12:59 -0400, Tom Lane wrote: >>> >>>>> I think we should fix it now. Quick thought: maybe we could use >>>>> >>>> FOR >>>> >>>>> instead of AS: select myfunc(7 for a, 6 for b); >>>>> >>>> I'm afraid FOR doesn't work either; it'll create a conflict with the >>>> spec-defined SUBSTRING(x FOR y) syntax. >>>> >>> How about >>> >>> select myfunc(a := 7, b := 6); >>> >> >> One concern I have is that in PL/pgSQL, := and = behave the same, while >> in SQL, they would not. That might cause confusion. >> >> > > That is a sad wart that we should never have done, IMNSHO (it was before > my time or I would have objected ;-) ). But beyond that, = is an > operator in SQL and := is never an operator, IIRC. As far as I can tell, this was already in the code when Bruce moved it into core as -r1.1 on my behalf (before I had commit privileges). I do not recall if the = as alternative to := was my idea or not. But I'm willing to take the blame for it because it dates back to a time where convenience seemed important. Jan -- Anyone who trades liberty for security deserves neither liberty nor security. -- Benjamin Franklin -- 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: Joseph Adams on 4 Jun 2010 22:07
On Fri, Jun 4, 2010 at 9:55 PM, Joseph Adams <joeyadams3.14159(a)gmail.com> wrote: > If I had to choose between => and := for parameter naming, I'd go with > := because it seems more SQLish to me. On second thought, => might actually be a very intuitive syntax for defining dictionary types like hstore and json, since it matches PHP's associative array syntax, as in: hstore('key1' => 'value1', 'key2' => 'value2') -- hypothetical SQL array('key1' => 'value1', 'key2' => 'value2') // PHP That way, when people see =>, they can think "dictionary" whether they're in PHP or SQL. Note that this is a bit different than what I suggested earlier: hstore(key1 => 'value1', key2 => 'value2') Identifier names were used instead of literal names, which conflicts with the other approach. Also, the other approach is more flexible, as the user can generate names with expressions at runtime. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |