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 4F94A185.3010808@wulczer.org
Whole thread Raw
In response to Re: plpython triggers are broken for composite-type columns  (Jan Urbański <wulczer@wulczer.org>)
Responses Re: plpython triggers are broken for composite-type columns  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On 10/04/12 21:47, Jan Urbański wrote:
> On 10/04/12 21:27, Tom Lane wrote:
>> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?=<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.

It turned out not to be as straightforward as I though :(

The I/O code in PL/Python is a bit of a mess and that's something that
I'd like to address somewhere in the 9.3 development cycle. Right now
making the conversion function recursive is not possible without some
deep surgery (or kludgery...) so I limited myself to producing
regression-fixing patches for 9.2 and 9.1 (attached).

Cheers,
Jan

Attachment

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: [BUG] Checkpointer on hot standby runs without looking checkpoint_segments
Next
From: Alexander Korotkov
Date:
Subject: Patch: add conversion from pg_wchar to multibyte