Re: Proposal: Solving the "Return proper effected tuple - Mailing list pgsql-hackers

From Joe Conway
Subject Re: Proposal: Solving the "Return proper effected tuple
Date
Msg-id 3D7C18C7.1010602@joeconway.com
Whole thread Raw
In response to Re: Proposal: Solving the "Return proper effected tuple count  (Bruce Momjian <pgman@candle.pha.pa.us>)
List 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



pgsql-hackers by date:

Previous
From: Steve Howe
Date:
Subject: Re: Proposal: Solving the "Return proper effected tuple count
Next
From: Steve Howe
Date:
Subject: Re: Proposal: Solving the "Return proper effected tuple count