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.
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 |