Re: plpython triggers are broken for composite-type columns

=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <wulczer(at)wulczer(dot)org> writes:
> On 10/04/12 20:47, Tom Lane wrote:
>> On reflection, can't we fix this as follows: if the value coming in from
>> Python is a string, just feed it to record_in, the same as we used to.
>> When I traced through the logic before, it seemed like it was failing
>> to distinguish strings from sequences, but I would hope that Python
>> is more strongly typed than that.

> Yeah, we can fix PLyObject_ToTuple to check for strings too and use the
> default PG input function. The reason it was complaining about length is
> that we're checking if the object passed implements the sequence
> protocol, which Python strings do (length, iteration, etc). Sticking a
> if branch that will catch the string case above that should be sufficient.

Ah, makes sense then. (Perhaps the dict case ought to be tested before
the sequence case, too, just to be safe?)

>> I still think the conversion in the other direction ought to yield a
>> dict, but that's clearly not back-patch material.

> 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.

> 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.

regards, tom lane