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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
