Re: plpython triggers are broken for composite-type columns - Mailing list pgsql-hackers

From Jan Urbański
Subject Re: plpython triggers are broken for composite-type columns
Date
Msg-id 4F848E54.3030601@wulczer.org
Whole thread Raw
In response to Re: plpython triggers are broken for composite-type columns  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: plpython triggers are broken for composite-type columns  (Jan Urbański <wulczer@wulczer.org>)
List pgsql-hackers
On 10/04/12 21:27, Tom Lane wrote:
> Jan Urbański<wulczer@wulczer.org>  writes:
>> Yes, that would be ideal, even though not backwards-compatible.
>> Back-patching is out of the question, but do we want to change trigger
>> functions to receive dictionaries in NEW?
>
> Hm, I was not thinking of this as being trigger-specific, but more a
> general principle that composite columns of tuples ought to be handled
> in a recursive fashion.

Sure, that would be the way.

>> If so, should this be 9.2 material, or just a TODO?
>
> If it can be done quickly and with not much risk, I'd vote for
> squeezing it into 9.2, because it seems to me to be a clear bug that the
> two directions are not handled consistently.  If you don't have time for
> it now or you don't think it would be a small/safe patch, we'd better
> just put it on TODO.

I'll see if making the conversion function recursive is easy and 
independently whip up a patch to check for strings and routes them 
through InputFunctionCall, for back-patching purposes.

Cheers,
Jan


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: plpython triggers are broken for composite-type columns
Next
From: Robert Haas
Date:
Subject: Re: Last gasp