Re: Allow SQL/plpgsql functions to accept record

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

In response to

Responses

Browse pgsql-hackers by date

  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.