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

From Bruce Momjian
Subject Re: Proposal: Solving the "Return proper effected tuple
Date
Msg-id 200209100224.g8A2OJr04571@candle.pha.pa.us
Whole thread Raw
In response to Re: Proposal: Solving the "Return proper effected tuple  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Proposal: Solving the "Return proper affected tuple
List pgsql-hackers
Peter Eisentraut wrote:
> Steve Howe writes:
> 
> > Here are the proposals for solutioning the "Return proper effected
> > tuple count from complex commands [return]" issue as seen on TODO.
> >
> > Any comments ?... This is obviously open to voting and discussion.
> 
> We don't have a whole lot of freedom in this; this area is covered by the
> SQL standard.  The major premise in the standard's point of view is that
> views are supposed to be transparent.  That is, if
> 
>     SELECT * FROM my_view WHERE condition;
> 
> return N rows, then a subsequently executed
> 
>     UPDATE my_view SET ... WHERE condition;
> 
> returns an update count of N, no matter what happens behind the scenes.  I
> don't think this matches Tom Lane's view exactly, but it's a lot closer
> than your proposal.

Oh, this is bad news.  The problem we have is that rules don't
distinguish the UPDATE on the underlying tables of the rule from other
updates that may appear in the query.

If we go with Tom's idea and total just UPDATE's, we will get the right
answer when there is only one UPDATE in the ruleset.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Rod Taylor
Date:
Subject: Re: Rule updates and PQcmdstatus() issue
Next
From: Tom Lane
Date:
Subject: Re: problem with new autocommit config parameter and jdbc