The following bug has been logged online: Bug reference: 3847 Logged by: Mark Reid Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.5 Operating system: Debian Linux Description: plpython trigger caches table structure - doesn't see new / changed columns Details:
If a column is added, dropped, then re-added (all within a transaction), a plpython trigger function loses track of the column and throws an error when trying to access it. Here is the best minimal test case I could come up with: ----------------- TEST 1 ---------------- BEGIN; CREATE TABLE clarence (pick_id int, foo varchar, bar varchar, baz varchar); INSERT INTO clarence (pick_id) values (1454); INSERT INTO clarence (pick_id) values (1453); CREATE OR REPLACE FUNCTION debug_columns() RETURNS "trigger" AS $BODY$ if TD["event"].upper() == "UPDATE": plpy.notice('test4: %s' % (TD["new"]["test4"])) return "OK" $BODY$ LANGUAGE 'plpythonu' VOLATILE; CREATE TRIGGER clarence_debug_trg AFTER UPDATE ON clarence FOR EACH ROW EXECUTE PROCEDURE debug_columns(); -- This works alter table clarence add column test4 varchar; update clarence set test4=12 where pick_id=1454; alter table clarence drop column test4; -- This does not work alter table clarence add column test4 varchar; update clarence set test4=12 where pick_id=1454; -- this creates a problem... plpgsql seems to work fine. alter table clarence drop column test4; ROLLBACK; ------------------ END TEST 1 -------------- Here is another test case that may come in handy (it enumerates the names of all the columns in the "new" record): -------------------- TEST 2 ------------------- BEGIN; CREATE TABLE clarence (pick_id int, foo varchar, bar varchar, baz varchar); INSERT INTO clarence (pick_id) values (1454); INSERT INTO clarence (pick_id) values (1453); CREATE OR REPLACE FUNCTION debug_columns() RETURNS "trigger" AS $BODY$ if TD["event"].upper() == "UPDATE": for key, val in TD["new"].iteritems(): plpy.notice('%s = [%s]' % (key, val)) return "OK" $BODY$ LANGUAGE 'plpythonu' VOLATILE; CREATE TRIGGER clarence_debug_trg AFTER UPDATE ON clarence FOR EACH ROW EXECUTE PROCEDURE debug_columns(); -- This works alter table clarence add column test4 varchar; update clarence set test4=12 where pick_id=1454; alter table clarence drop column test4; -- This does not work --alter table clarence add column test4 varchar; --update clarence set test4=12 where pick_id=1454; -- this creates a problem... plpgsql seems to work fine. --alter table clarence drop column test4; -- This works alter table clarence add column test5 varchar; update clarence set test5=12 where pick_id=1454; alter table clarence drop column test5; ROLLBACK; ---------------- END TEST 2 ------------------- I would be willing to take a stab at fixing this, but would need someone more experienced to give me some pointers as to how to go about it (i've never looked at the PG source). -Mark. ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match