From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
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-10 02:24:19 |
Message-ID: | 200209100224.g8A2OJr04571@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-09-10 02:27:03 | Re: problem with new autocommit config parameter and jdbc |
Previous Message | Vanmunin Chea | 2002-09-10 02:23:45 | If there a bug in the psql or just a feature . |