From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Mike Glover <mpg4(at)mdi(dot)cc> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: ON DELETE triggers don't work as documented |
Date: | 2002-12-11 18:18:08 |
Message-ID: | 3DF78160.9040606@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Mike Glover wrote:
> Please enter a FULL description of your problem:
> ------------------------------------------------ The docs state (section
> 23.9):
>
> If a non-NULL value is returned then the operation proceeds with that row
> value. Note that returning a row value different from the original value of
> NEW alters the row that will be inserted or updated.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> the above suggests that returning NEW for a delete should cause the delete
> to proceed. In fact, I've found it necessary to return a record with the
> row format of the table and all empty fields.
No, actually it suggests that returning NEW should cause an *update* or
*insert* to proceed. In the case of a delete, NEW is not set. See a few lines
above:
NEW
Data type RECORD; variable holding the new database row for INSERT/UPDATE
operations in ROW level triggers.
OLD
Data type RECORD; variable holding the old database row for UPDATE/DELETE
operations in ROW level triggers.
It is perhaps confusing, but probably necessary so that a single function can
handle inserts, updates, and deletes (see TG_OP).
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Rudy Lippan | 2002-12-12 03:21:54 | initdb segfaulting. |
Previous Message | Stephan Szabo | 2002-12-11 16:37:28 | Re: bug or feature? |