In a plpython trigger, if you return "MODIFY", the parsing of the
TD["new"] dictionary uses the wrong (c array) index to locate the
atttypmod value, leading to subtle bugs dependent on the exact types,
names, and order of fields in the table in question.
(Types need to be those that use the typmod, names affect the ordering
in the python dictionary, and order affects the c array).
In my case, I ended up with TIMESTAMP(68), which was just slightly
more precision than I really wanted ;-)
Here's a patch that fixes my issue. I have not extensively developed
tests for it.
-Brad
-----
diff -ur postgresql-7.3.2.orig/src/pl/plpython/plpython.c
postgresql-7.3.2/src/pl/plpython/plpython.c
--- postgresql-7.3.2.orig/src/pl/plpython/plpython.c Fri Jan 31 17:35:27 2003
+++ postgresql-7.3.2/src/pl/plpython/plpython.c Wed Feb 12 19:22:08 2003
@@ -630,7 +630,7 @@
modvalues[j] =
FunctionCall3(&proc->result.out.r.atts[atti].typfunc,
CStringGetDatum(src),
ObjectIdGetDatum(proc->result.out.r.atts[atti].typelem),
-
Int32GetDatum(tupdesc->attrs[j]->atttypmod));
+
+Int32GetDatum(tupdesc->attrs[atti]->atttypmod));
modnulls[j] = ' ';
Py_DECREF(plstr);
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
