Re: Composite Types and Function Parameters
Andrew Dunstan <adunstan@postgresql.org>
From: Andrew Dunstan <adunstan@postgresql.org>
To:
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Merlin Moncure <mmoncure@gmail.com>, Greg <grigorey@yahoo.co.uk>, Pavel Stehule <pavel.stehule@gmail.com>, pgsql-hackers@postgresql.org
Date: 2010-10-28T03:00:16Z
Lists: pgsql-hackers
On 10/25/2010 09:32 PM, Andrew Dunstan wrote:
>
>
> On 10/25/2010 07:12 PM, Tom Lane wrote:
>> However, that objection doesn't hold for plperl or pltcl (and likely
>> not plpython, though I don't know that language enough to be sure).
>> So it would be a reasonable feature request to teach those PLs to
>> accept "record" parameters. I think the fact that they don't stems
>> mostly from nobody having revisited their design since the
>> infrastructure that supports record_out was created.
>
> That seems like a good idea. I'll look at it for plperl.
A naive implementation turns out to be really trivial. It's about two
lines, and we can then do:
andrew=# create function rfunc (x record) returns text language
plperlu as $$ use Data::Dumper; return Dumper(shift); $$;
CREATE FUNCTION
andrew=# select rfunc(row(c.relname,n.nspname)) from pg_class c join
pg_namespace n on c.relnamespace = n.oid limit 1;
rfunc
--------------------------------------
$VAR1 = '(pg_statistic,pg_catalog)';+
But I think we can do better than this. We should really pass an hashref
with the record's column names as keys rather than just calling
record_out. I'll work on that.
cheers
andrew