From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | plpython triggers are broken for composite-type columns |
Date: | 2012-04-10 02:20:06 |
Message-ID: | 18828.1334024406@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Browne | 2012-04-10 03:12:10 | Re: Last gasp |
Previous Message | Kris Jurka | 2012-04-10 01:36:55 | Re: Regarding GSoc proposal |