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