Skip site navigation (1) Skip section navigation (2)

Re: Composite Types and Function Parameters

From: Andrew Dunstan <adunstan(at)postgresql(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Greg <grigorey(at)yahoo(dot)co(dot)uk>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Composite Types and Function Parameters
Date: 2010-10-28 03:00:16
Message-ID: (view raw, whole thread or download thread mbox)
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); $$;
    andrew=# select rfunc(row(c.relname,n.nspname)) from pg_class c join
    pg_namespace n on c.relnamespace = n.oid limit 1;
      $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.



In response to

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2010-10-28 03:02:01
Subject: Re: Composite Types and Function Parameters
Previous:From: Robert HaasDate: 2010-10-28 02:01:07
Subject: Re: Re: Postgres insert performance and storage requirement compared to Oracle

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group