Re: BUG #3847: plpython trigger caches table structure - doesn't see new / changed columns

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Mark Reid" <reid(dot)write(at)gmail(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #3847: plpython trigger caches table structure - doesn't see new / changed columns
Date: 2008-01-01 19:17:58
Message-ID: 18048.1199215078@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"Mark Reid" <reid(dot)write(at)gmail(dot)com> 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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Ion 2008-01-01 20:11:01 BUG #3848: function pg_catalog.substring(date, integer, integer) does not exist
Previous Message Simon Riggs 2008-01-01 01:40:11 Re: Duplicate values found when reindexing unique index