hstore ==> and deprecate =>
in [PgSql]
|
From: Tom Lane on 12 Jun 2010 08:57 Peter Eisentraut <peter_e(a)gmx.net> writes: > On fre, 2010-06-11 at 10:57 -0400, Tom Lane wrote: >> 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) Yeah, but the *left* side still has to be a special datatype that doesn't exist today. So we have at least some chance of not usurping existing usages of the operator name. In principle you could have transformAExprOp transform the left side and then check for this case before trying to transform the right side. (And in any case, I haven't noticed anybody expressing any interest in implementing that part of the spec.) But actually, there's another issue here: hstore defines not one but three => operators: text => text yields hstore (with 1 element) text[] => text[] yields hstore (with N elements) hstore => text[] yields hstore (subset) It's reasonable to say that the first two are bad design, but I'm a bit less willing to say that the last one is. What shall we do with that? 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: Florian Pflug on 12 Jun 2010 10:15 On Jun 12, 2010, at 14:57 , Tom Lane wrote: > But actually, there's another issue here: hstore defines not one but > three => operators: > > text => text yields hstore (with 1 element) > text[] => text[] yields hstore (with N elements) > hstore => text[] yields hstore (subset) > > It's reasonable to say that the first two are bad design, but I'm > a bit less willing to say that the last one is. What shall we > do with that? Hm, the last one seems to be more akin to hstore - text yields hstore (key removed) hstore - text[] yields hstore (keys in array removed) hstore - hstore yields hstore (keys in hstore removed) since it's not a constructor like the first two, but rather an (intersection-like) operation on an existing hstore. Inspired by the already existing hstore ?& text[] yields boolean (true if set of keys subset of array) I suggest hstore & text[] as a replacement. best regards, Florian Pflug -- 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 12 Jun 2010 12:23 On Jun 11, 2010, at 2:23 PM, Tom Lane wrote: >> 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: Is not the first one simply a function with any number of named params? 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 12 Jun 2010 12:29 On Jun 12, 2010, at 7:15 AM, Florian Pflug wrote: >> It's reasonable to say that the first two are bad design, but I'm >> a bit less willing to say that the last one is. What shall we >> do with that? > > Hm, the last one seems to be more akin to > hstore - text yields hstore (key removed) > hstore - text[] yields hstore (keys in array removed) > hstore - hstore yields hstore (keys in hstore removed) Well, no, the keys aren't removed: you get back an hstore with only those keys (the lhs is unchanged). > since it's not a constructor like the first two, but rather an (intersection-like) operation on an existing hstore. > > Inspired by the already existing > hstore ?& text[] yields boolean (true if set of keys subset of array) > I suggest > hstore & text[] > as a replacement. Yes, agreed. That just leaves text[] => text[] yields hstore (with N elements) Which, IIRC, is new in 9.1, so could in theory be removed, especially if there was an hstore(text[], text[]) 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 12 Jun 2010 13:01
"David E. Wheeler" <david(a)kineticode.com> writes: > On Jun 11, 2010, at 2:23 PM, Tom Lane wrote: >>> 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: > Is not the first one simply a function with any number of named params? No, because the desire presumably would be to be able to use any set of parameter names with that one function ... which absolutely flies in the face of our current notion of what a parameter name means. You'd essentially have to disable the ability to have function overloading. (Which probably means it Ain't Happening.) 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 |