Re: plpython triggers are broken for composite-type columns

=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <wulczer(at)wulczer(dot)org> writes:
>> On 10/04/12 04:20, Tom Lane wrote:
>>> Don't know if anybody noticed bug #6559
>>> http://archives.postgresql.org/pgsql-bugs/2012-03/msg00180.php

> So, I know what's going on, I still don't know what's the best way to
> handle it.

> The function that converts Python objects to PG data checks what type
> it's supposed to produce and acts accordingly. In 9.0 it checked for
> bool, bytea and arrays, in 9.1 it also takes composite types into account.

> This has been done to support functions returning composite types - to
> do that they need to return a dictionary or a list, for instance
> {'col1': 1, 'col2': 2}.

> The problem is that the routine that converts PG data into Python
> objects does not handle composite type inputs all that well - it just
> bails and returns the string representation, hence '(3)' appearing in
> Python land.

> Now previously, the Python->PG function did not see that the given
> conversion is supposed to return a composite so it also bailed and used
> a default text->composite conversion, so '(3)' was converted to ROW(3)
> and all went well. The new code tries to treat what it gets as a
> dictionary/list/tuple and fails in a more or less random way.

> Now that I understand what's been going on, I'll try to think of a
> non-invasive way of fixing that...

ISTM that conversion of a composite value to Python ought to produce a
dict, now that the other direction expects a dict. I can see that this
is probably infeasible for compatibility reasons in 9.1, but it's not
too late to fix it for 9.2. We might have to leave the bug unfixed in
9.1, since anything we do about it will represent a compatibility break.

regards, tom lane