hstore ==> and deprecate =>
in [PgSql]
|
From: "David E. Wheeler" on 11 Jun 2010 12:59 On Jun 11, 2010, at 9:58 AM, Tom Lane wrote: >> 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. Yes, sorry. 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: Joseph Adams on 11 Jun 2010 16:58 On Fri, Jun 11, 2010 at 10:59 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > 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 > To repeat an earlier question (which was in turn repeating an earlier question), would it be possible to do one of these, yielding ' "key"=>"this", "key2"=>"that" '::hstore : hstore(key := 'this', key2 := 'that') hstore(key => 'this', key2 => 'that') hstore(row('this' AS key, 'that' AS key2)) In my opinion, it's important to find a reasonably elegant way to express hstore literals (rather than something like hstore(hstore_kvp('key', 'this'), hstore_kvp('key2', 'that')) ) because something so basic shouldn't be so difficult to work with. It'd be a bonus if there was a general form for arbitrary named parameters that new functions could opt-in on (in particular, json_object :-) ). This type of function could be created by saying something like: CREATE FUNCTION hstore(NAMED) RETURNS hstore AS ... -- NAMED would be a new argtype Also, if a user needs to name a field from a variable, perhaps there should be a syntax that allows it, such as: hstore(pg_deref(var) => 'this', pg_deref(var2) => 'that') If implementing pg_deref would be problematic in general, perhaps it could initially just be supported in keys of functions like this. Only if we allow for functions with named parameters in this fashion would I say +1 for deprecating the => operator from hstore without a replacement operator like ==> . Joey Adams -- 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 17:23 Joseph Adams <joeyadams3.14159(a)gmail.com> writes: > To repeat an earlier question (which was in turn repeating an earlier > question), would it be possible to do one of these, yielding ' > "key"=>"this", "key2"=>"that" '::hstore : > hstore(key := 'this', key2 := 'that') > hstore(key => 'this', key2 => 'that') > hstore(row('this' AS key, 'that' AS key2)) The last of those is probably the easiest to get to. We already have hstore_from_record: contrib_regression=# select hstore(row('this', 'that')); hstore ---------------------------- "f1"=>"this", "f2"=>"that" (1 row) and the only thing lacking is an easy way to specify the column names associated with the anonymous record type. Extending the ROW() construct with AS labels as suggested above might be a reasonable way. 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: Merlin Moncure on 11 Jun 2010 21:00 On Fri, Jun 11, 2010 at 5:23 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Joseph Adams <joeyadams3.14159(a)gmail.com> writes: >> To repeat an earlier question (which was in turn repeating an earlier >> question), would it be possible to do one of these, yielding ' >> "key"=>"this", "key2"=>"that" '::hstore �: > >> hstore(key := 'this', key2 := 'that') >> hstore(key => 'this', key2 => 'that') >> hstore(row('this' AS key, 'that' AS key2)) > > The last of those is probably the easiest to get to. �We already have > hstore_from_record: > > contrib_regression=# select hstore(row('this', 'that')); > � � � � � hstore > ---------------------------- > �"f1"=>"this", "f2"=>"that" > (1 row) > > and the only thing lacking is an easy way to specify the column names > associated with the anonymous record type. �Extending the ROW() > construct with AS labels as suggested above might be a reasonable way. +1 A couple of people were just requesting that very thing (ROW/AS) on the IRC channel today. row() is a pretty useful mechanism and it would be nice to have it more defensible vs. table changes. merlin -- 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: Peter Eisentraut on 12 Jun 2010 04:04
On fre, 2010-06-11 at 10:57 -0400, Tom Lane wrote: > 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 =>). The right side of the -> would be an identifier, like (some expr yielding a ref)->attribute or objref->method(args) -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |