On 10/04/12 07:35, Jan Urbański wrote:
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
I've confirmed that the given test case works in 9.0 but fails in
9.1 and HEAD.
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...
Cheers,
Jan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
