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. It's not terribly sensitive to the details of the
SQL: any non-null value for the composite column fails, for instance
you can try
INSERT INTO tbl VALUES (row(3), 4);
and it spits up just the same. The long and the short of it is that
PLy_modify_tuple fails to make sense of what PLyDict_FromTuple
produced for the table row.
I tried to trace through things to see exactly where it was going wrong,
and noted that
(1) When converting the table row to a Python dict, the composite
column value is fed through the generic PLyString_FromDatum() function,
which seems likely to be the wrong choice.
(2) When converting back, the composite column value is routed to
PLyObject_ToTuple, which decides it is a Python sequence, which seems
a bit improbable considering it was merely a string a moment ago.
I find this code pretty unreadable, though, and know nothing to
speak of about the Python side of things anyhow. So somebody else
had better pick this up.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
