In article <200401201905.46699.dev@archonet.com>,
Richard Huxton <dev@archonet.com> writes:
> On Tuesday 20 January 2004 16:42, Tom Lane wrote:
>> Harald Fuchs <hf118@protecting.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.
I would not say so. You could use tables without primary keys, and
you could define statement-level triggers on them, but you could not
identify a particular row in this very special and probably rare case.
> 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.
When I read about the "insert" and "delete" pseudotables in a book
about Transact-SQL, i was enthusiastic about the elegance of this
idea: you're operating on multiple (perhaps lots of) rows, and the SQL
way of doing that is by set-operations, i.e. single operations
affecting a set of rows. Pseudotables extend this idea nicely into
the area of statement-level triggers. Your cursor idea doesn't look
very SQL-like to me.
We really should find an Oracle/DB2/Informix guy who can tell us how
to get that right.