Re: Trigger question

From: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
To: Harald Fuchs <hf118(at)protecting(dot)net>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Trigger question
Date: 2004-01-20 16:30:29
Message-ID: 20040120082719.S69928@megazone.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, 20 Jan 2004, Harald Fuchs wrote:

> In article <24300(dot)1074614549(at)sss(dot)pgh(dot)pa(dot)us>,
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
> > Richard Huxton <dev(at)archonet(dot)com> writes:
> >> On Tuesday 20 January 2004 00:01, Neil Conway wrote:
> >>> Yeah, I didn't get around to implementing that. If anyone wants this
> >>> feature, I'd encourage them to step up to the plate -- I'm not sure
> >>> when I'll get the opportunity/motivation to implement this myself.
>
> >> I didn't think they'd be meaningful for a statement-level trigger. Surely
> >> OLD/NEW are by definition row-level details.
>
> > According to the complainants, OLD/NEW are commonly available as
> > recordsets (tables) inside a statement trigger.
>
> Yes.
>
> > I'm not very clear on
> > how that works myself --- in particular, one would think it important to
> > be able to work with corresponding pairs of OLD and NEW rows, which
> > would be painful with a table-like abstraction.
>
> Why? If the underlying table has a primary key, finding corresponding
> pairs is trivial; if there isn't, it's impossible.

I don't think that's sufficient unless you can guarantee that the primary
key values never change for any reason that causes the trigger to try to
correspond them.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2004-01-20 16:42:30 Re: Trigger question
Previous Message Harald Fuchs 2004-01-20 16:15:31 Re: Trigger question