Re: Trigger question

From: Harald Fuchs <hf118(at)protecting(dot)net>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: Trigger question
Date: 2004-01-21 13:50:26
Message-ID: puptdd2yxp.fsf@srv.protecting.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Stephan Szabo 2004-01-21 16:45:00 Re: Trigger question
Previous Message Dennis Bjorklund 2004-01-21 10:42:01 Re: Really slow even after vacuum