Re: hstore ==> and deprecate => - Mailing list pgsql-hackers

From Joseph Adams
Subject Re: hstore ==> and deprecate =>
Date
Msg-id AANLkTil5AOKbkN5m6QeYqf9PE4Q1THreRGbkDcpDMseO@mail.gmail.com
Whole thread Raw
In response to Re: hstore ==> and deprecate =>  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: hstore ==> and deprecate =>  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Jun 11, 2010 at 10:59 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Peter Eisentraut <peter_e@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@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


pgsql-hackers by date:

Previous
From: Dimitri Fontaine
Date:
Subject: Re: Command to prune archive at restartpoints
Next
From: Tom Lane
Date:
Subject: Re: hstore ==> and deprecate =>