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

Re: Composite Types and Function Parameters

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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 04:08:39
Message-ID: 4CC8F747.9010001@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackers

On 10/27/2010 11:38 PM, Tom Lane wrote:
> Andrew Dunstan<andrew(at)dunslane(dot)net>  writes:
>> 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.
> Definitely.  If you aren't providing that info then it's hard to write
> a generic function, which is more or less the whole point here.  I'd
> even argue that it'd be nice if the function could find out the data
> types of the record's columns; though I have no idea what a reasonable
> API for that would be in Perl.



Well, it turns out that the hashref required exactly one more line to 
achieve. We already have all the infrastructure on the composite 
handling code, and all it requires it to enable it for the RECORDOID case.

As for your idea of exposing type info, we could certainly do that using 
the same mechanism we use for the trigger $_TD stuff.

Patch so far attached.

cheers

andrew

Attachment: plperl-record-args.patch
Description: text/x-patch (1.8 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Josh BerkusDate: 2010-10-28 05:13:26
Subject: Re: Simplifying replication
Previous:From: Tom LaneDate: 2010-10-28 03:38:23
Subject: Re: Composite Types and Function Parameters

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