hstore ==> and deprecate =>
in [PgSql]
|
From: Peter Eisentraut on 11 Jun 2010 07:49 On tis, 2010-06-08 at 15:38 -0400, Robert Haas wrote: > I'm happy to do whatever the consensus is. I thought it would be > easier to remember if the two operators were spelled at least somewhat > similarly, but I just work here. How about no operator at all? It won't be as cool to read, but consider, the arguments are text and text, not involving any hstore type at all, so whatever operator you choose is in practice blocked from everyone everywhere. No one could ever implement another key/value system that uses a similar interface. Or use the operator for anything else involving strings. Why not just write: hstore('this', 'that') hstore(key := 'this', value := 'that') -- 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 11 Jun 2010 10:57 Peter Eisentraut <peter_e(a)gmx.net> writes: >>> Btw., the SQL standard also defines -> for something else, so if you >>> wanted to be really visionary, you could deprecate that one as an >>> operator at the same time. >> >> Ouch. What does it define it to mean? > Similar to C: Dereferencing a reference and accessing a member. But a reference would be a datatype no? So we could just regard that as an ordinary operator. I don't see a reason why it would conflict with use of the same operator name for other datatypes (unlike the situation with =>). 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: Tom Lane on 11 Jun 2010 10:59 Peter Eisentraut <peter_e(a)gmx.net> writes: > How about no operator at all? It won't be as cool to read, but > consider, the arguments are text and text, not involving any hstore type > at all, so whatever operator you choose is in practice blocked from > everyone everywhere. No one could ever implement another key/value > system that uses a similar interface. Or use the operator for anything > else involving strings. Yeah, that's a good point. Maybe we should just deprecate the operator altogether. 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: "David E. Wheeler" on 11 Jun 2010 11:36 On Jun 11, 2010, at 7:59 AM, Tom Lane wrote: >> How about no operator at all? It won't be as cool to read, but >> consider, the arguments are text and text, not involving any hstore type >> at all, so whatever operator you choose is in practice blocked from >> everyone everywhere. No one could ever implement another key/value >> system that uses a similar interface. Or use the operator for anything >> else involving strings. > > Yeah, that's a good point. Maybe we should just deprecate the operator > altogether. That would make it so that the use of => in hstore strings would be less consistent. Makes sense to me. 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: Tom Lane on 11 Jun 2010 12:58
"David E. Wheeler" <david(a)kineticode.com> writes: > On Jun 11, 2010, at 7:59 AM, Tom Lane wrote: >> Yeah, that's a good point. Maybe we should just deprecate the operator >> altogether. > That would make it so that the use of => in hstore strings would be less consistent. Makes sense to me. Less inconsistent, ITYM? But yeah, then we would have no reason to fiddle with hstore_in, which is good. 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 |