From: | Richard Huxton <dev(at)archonet(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Harald Fuchs <hf118(at)protecting(dot)net> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Trigger question |
Date: | 2004-01-20 19:05:46 |
Message-ID: | 200401201905.46699.dev@archonet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tuesday 20 January 2004 16:42, Tom Lane wrote:
> Harald Fuchs <hf118(at)protecting(dot)net> writes:
> > Why? If the underlying table has a primary key, finding corresponding
> > pairs is trivial; if there isn't, it's impossible.
>
> Exactly. Nonetheless, the correspondence exists --- the UPDATE
> definitely updated some particular row of the OLD set into some
> particular one of the NEW set. If the trigger API makes it impossible
> to reconstruct the matchup, the API is broken.
Perhaps they should be cursors? The only sensible way I can think of working
with them would be:
1. count how many rows affected
2. step through one row at a time, doing something.
I suppose there might be cases where you'd want to GROUP BY... which would
mean you'd need some oid/row-id added to a "real" recordset.
--
Richard Huxton
Archonet Ltd
From | Date | Subject | |
---|---|---|---|
Next Message | Orion Henry | 2004-01-20 19:47:09 | database profiling |
Previous Message | Tom Lane | 2004-01-20 16:42:30 | Re: Trigger question |