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

From Steve Howe
Subject Re: Proposal: Solving the "Return proper effected tuple count
Date
Msg-id 4485851027.20020909004437@carcass.dhs.org
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
Hello Bruce,

Monday, September 9, 2002, 12:36:38 AM, you wrote:

BM> Joe Conway wrote:
>> Sure, but that's why I am in favor of changing the tag. If you did:
>> 
>> DELETE FROM fooview WHERE name LIKE 'Joe%';
>> 
>> and got:
>> 
>> MUTATED 507324 3
>> 
>> it would mean that 3 tuples in total were affected by all of the 
>> substitute operations, only of of them being an INSERT, and the Oid of 
>> the lone INSERT was 507324. If instead I got:
>> 
>> DELETE 0
>> 
>> I'd be back to having no useful information. Did any rows in fooview 
>> match the criteria "LIKE 'Joe%'"? Did any data in my database get 
>> altered? Can't tell from this.

BM> OK.  Do any people have INSTEAD rules where there are not commands
BM> matching the original query tag?  Can anyone think of such a case being
BM> created?
I can think a thousand cases.
For instance, one could create an update rule that would delete rows
referenced on a second table (to avoid orphan rows). OR a user could
make an insert rule that empties a table with DELETE so that only one
row can always be assumed in that table... the possibilities are
infinite.

BM> The only one I can think of is UPDATE implemented as separate INSERT and
BM> DELETE commands.
I'm afraid the great imagination of PostgreSQL users has come to all
kind of uses and misuses for such a powerful feature :)

------------- 
Best regards,Steve Howe                           mailto:howe@carcass.dhs.org



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Proposal: Solving the "Return proper effected tuple
Next
From: Joe Conway
Date:
Subject: Re: Proposal: Solving the "Return proper effected tuple