Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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


pgsql-performance by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group