Re: Trigger question

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.