On 10/04/12 20:47, Tom Lane wrote:
> I wrote:
>> Jan Urbański<wulczer@wulczer.org> writes:
>>> 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.
>
> 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.
>
> 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? If so, should this be 9.2
material, or just a TODO?