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