Re: hstore ==> and deprecate =>

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "David E(dot) Wheeler" <david(at)kineticode(dot)com>
Cc: Joseph Adams <joeyadams3(dot)14159(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: hstore ==> and deprecate =>
Date: 2010-06-12 17:01:02
Message-ID: 28224.1276362062@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"David E. Wheeler" <david(at)kineticode(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2010-06-12 17:12:33 Re: pg_upgrade output directory
Previous Message Tom Lane 2010-06-12 16:54:55 Re: Idea for getting rid of VACUUM FREEZE on cold pages