From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Allow SQL/plpgsql functions to accept record |
Date: | 2015-04-22 22:12:59 |
Message-ID: | 55381CEB.7050707@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 4/22/15 2:12 PM, Merlin Moncure wrote:
> That being said, I think json types with their associated API, given
> that they are core types, will ultimately handle these types of
> problems. That way, at least, we can avoid adding syntax and
> functionality that will basically do the same thing. This reminds me
> a little bit of the json_build() vs enhanced row() syntax we discussed
> some time back. I didn't say so at the time, but for posterity, I
> think you were right...json_build() is working fine for building
> arbitrary record types and moving a record to json and deconstructing
> it should work just as well.
The one part I don't care for in that is it seems rather inefficient to
cast something to JSON just so we can do things we really should be able
to do with a record. But perhaps it's not all that costly.
As for allowing SQL and plpgsql functions to accept a record, I think
our JSON functionality just provided plenty of reason we should allow
accepting them, even if you can't do much with it: you *can* hand it to
row_to_json(), which does allow you to do something useful with it. So
it seems reasonable to me that we should at least accept it as a
function argument.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2015-04-22 22:23:16 | Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0 |
Previous Message | Jim Nasby | 2015-04-22 22:05:32 | Re: Freeze avoidance of very large table. |