On 10/25/2010 09:32 PM, Andrew Dunstan wrote: <blockquote cite="mid:4CC62FAA.7090505@dunslane.net" type="cite"><br
/><br/> On 10/25/2010 07:12 PM, Tom Lane wrote: <br /><blockquote type="cite">However, that objection doesn't hold for
plperlor pltcl (and likely <br /> not plpython, though I don't know that language enough to be sure). <br /> So it
wouldbe a reasonable feature request to teach those PLs to <br /> accept "record" parameters. I think the fact that
theydon't stems <br /> mostly from nobody having revisited their design since the <br /> infrastructure that supports
record_outwas created. <br /></blockquote><br /> That seems like a good idea. I'll look at it for plperl. <br
/></blockquote><br/> A naive implementation turns out to be really trivial. It's about two lines, and we can then
do:<br/><br /><blockquote>andrew=# create function rfunc (x record) returns text language plperlu as $$ use
Data::Dumper;return Dumper(shift); $$;<br /> CREATE FUNCTION<br /> andrew=# select rfunc(row(c.relname,n.nspname)) from
pg_classc join pg_namespace n on c.relnamespace = n.oid limit 1;<br /> rfunc <br />
--------------------------------------<br/> $VAR1 = '(pg_statistic,pg_catalog)';+<br /> <br /><br /></blockquote> But
Ithink we can do better than this. We should really pass an hashref with the record's column names as keys rather than
justcalling record_out. I'll work on that.<br /><br /> cheers<br /><br /> andrew<br />
