| 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: | Whole Thread | Raw Message | 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 |