"Mark Reid" <[EMAIL PROTECTED]> writes: > 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:
The cases you are saying work and don't work are exactly the same: > -- 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; Please be clearer. regards, tom lane ---------------------------(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