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

From: "Mark Reid" <reid(dot)write(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 23:42:26
Message-ID: 162057b00801011542k7bb8679fif4b072659ce981df@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

The trigger function does not recognize the "test4" column the second time
it is added - the update throws an error.

On Jan 1, 2008 11:17 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> "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 Bruce Momjian 2008-01-02 02:51:24 Re: BUG #3822: Nonstandard precedence for comparison operators
Previous Message Sam Mason 2008-01-01 21:39:41 Re: BUG #3848: function pg_catalog.substring(date, integer, integer) does not exist