Re: Trigger question

In article <200401201905(dot)46699(dot)dev(at)archonet(dot)com>,
Richard Huxton <dev(at)archonet(dot)com> writes:

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

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.