"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

Reply via email to