After reading the recent thread about python 2 vs python 3 support,
I thought I'd amuse myself by trying to get plpython3 supported in
the Fedora packages. That turned out to be unreasonably painful
(which is something we oughta fix eventually), but it worked,
at least with F16/F17. When I went to try to build it in rawhide,
I got these failures from the plpython_trigger regression test:
*** /builddir/build/BUILD/postgresql-9.2.0/src/pl/plpython/./python3/expected/pl
python_trigger.out Sat Sep 8 16:20:55 2012
--- /builddir/build/BUILD/postgresql-9.2.0/src/pl/plpython/./python3/results/plp
ython_trigger.out Sat Sep 8 16:21:07 2012
***************
*** 483,489 ****
BEFORE UPDATE ON trigger_test
FOR EACH ROW EXECUTE PROCEDURE stupid7();
UPDATE trigger_test SET v = 'null' WHERE i = 0;
! ERROR: key "a" found in TD["new"] does not exist as a column in the triggerin
g row
CONTEXT: while modifying trigger row
PL/Python function "stupid7"
DROP TRIGGER stupid_trigger7 ON trigger_test;
--- 483,489 ----
BEFORE UPDATE ON trigger_test
FOR EACH ROW EXECUTE PROCEDURE stupid7();
UPDATE trigger_test SET v = 'null' WHERE i = 0;
! ERROR: key "b" found in TD["new"] does not exist as a column in the triggerin
g row
CONTEXT: while modifying trigger row
PL/Python function "stupid7"
DROP TRIGGER stupid_trigger7 ON trigger_test;
***************
*** 497,503 ****
BEFORE UPDATE ON trigger_test
FOR EACH ROW EXECUTE PROCEDURE stupid7u();
UPDATE trigger_test SET v = 'null' WHERE i = 0;
! ERROR: key "a" found in TD["new"] does not exist as a column in the triggerin
g row
CONTEXT: while modifying trigger row
PL/Python function "stupid7u"
DROP TRIGGER stupid_trigger7 ON trigger_test;
--- 497,503 ----
BEFORE UPDATE ON trigger_test
FOR EACH ROW EXECUTE PROCEDURE stupid7u();
UPDATE trigger_test SET v = 'null' WHERE i = 0;
! ERROR: key "b" found in TD["new"] does not exist as a column in the triggerin
g row
CONTEXT: while modifying trigger row
PL/Python function "stupid7u"
DROP TRIGGER stupid_trigger7 ON trigger_test;
The test cases being complained of look like
-- TD keys not corresponding to row columns
CREATE FUNCTION stupid7() RETURNS trigger
AS $$
TD["new"] = {'a': 'foo', 'b': 'bar'}
return "MODIFY";
$$ LANGUAGE plpythonu;
and obviously, python is iterating through the hash's keys in a
different order than it was a minor version or two back. (The failure
is occurring with 3.3.0-0.4.rc1.fc19, whereas I saw no failure with
3.2.3-7.fc17.)
I think probably the best thing is to change the test case so it has one
valid key and one not-valid one, rather than assuming that the same key
will always be complained of when there's more than one not-valid one.
Any objections, or different analysis?
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
