From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Steve Howe <howe(at)carcass(dot)dhs(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Proposal: Solving the "Return proper effected tuple |
Date: | 2002-09-09 03:43:03 |
Message-ID: | 3D7C18C7.1010602@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian wrote:
> OK. Do any people have INSTEAD rules where there are not commands
> matching the original query tag? Can anyone think of such a case being
> created?
>
> The only one I can think of is UPDATE implemented as separate INSERT and
> DELETE commands.
>
I could see an UPDATE implemented as an UPDATE and an INSERT. You would
UPDATE the original row to mark it as dead (e.g. change END_DATE from
NULL to CURRENT_DATE), and INSERT a new row to represent the new state.
This is pretty common in business systems where you need complete
transaction history, and never update in place over critical data.
Similarly, a DELETE might be implemented as an UPDATE for the same
reason (mark it dead, but keep the data). In fact, the view itself might
screen out the dead rows using the field which was UPDATED.
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Steve Howe | 2002-09-09 03:44:37 | Re: Proposal: Solving the "Return proper effected tuple count |
Previous Message | Bruce Momjian | 2002-09-09 03:39:20 | Re: Proposal: Solving the "Return proper effected tuple |