Thread: Python version dependency in plpython regression tests

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

On Sat, 2012-09-08 at 16:35 -0400, Tom Lane wrote:
> 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.)

Yes, known problem with 3.3.
> 
> 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. 

That would probably work.  We dealt with a similar problem in
2cfb1c6f77734db81b6e74bcae630f93b94f69be, if you want some additional
inspiration.  Not sure why we didn't see this case then.

Peter Eisentraut <peter_e@gmx.net> writes:
> On Sat, 2012-09-08 at 16:35 -0400, Tom Lane wrote:
>> 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.

> That would probably work.  We dealt with a similar problem in
> 2cfb1c6f77734db81b6e74bcae630f93b94f69be, if you want some additional
> inspiration.  Not sure why we didn't see this case then.

If it's got anything to do with hashing, platform dependency wouldn't be
a bit surprising.  Or they might have tweaked the algorithm some more
since May.

How come you did not back-patch that commit ... are we not supporting
3.3 in branches before 9.2 for some reason?
        regards, tom lane

On Sat, 2012-09-08 at 16:52 -0400, Tom Lane wrote:
> How come you did not back-patch that commit ... are we not supporting
> 3.3 in branches before 9.2 for some reason? 

Python 3.3 isn't even released yet, much less so back then, so it seemed
premature.

Also, it's a fairly big change just to make the regression tests pass.