Skip site navigation (1) Skip section navigation (2)

Re: BUG #2671: incorrect return value by RULE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Toru SHIMOGAKI <shimogaki(dot)toru(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #2671: incorrect return value by RULE
Date: 2006-10-03 17:56:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> On Tue, 2006-10-03 at 11:04 -0400, Tom Lane wrote:
>> This is the long-ago-agreed-to behavior, see

> Understood this is not-a-bug, but it is an opportunity for the TODO.

> IMHO when we have a set of mutually exclusive conditional RULEs that it
> would be possible to identify the correct return value and display it.

What makes you think there is a single "correct" return value?  If
multiple rows are being inserted/updated it's entirely possible that
some of them will be in different child partitions.

If we were interested in changing the status behavior, I'd be inclined
to think about something like adding up the rowcounts from all the
replacement queries that're of the same type as the original.  However,
I have some recollection that this was proposed and shot down in the
discussions that led to the current solution --- as a counterexample
consider an ON INSERT DO ALSO that inserts rows into a logging table.
This should be hidden from the user but would not be if we added its
effects to the result tag.

			regards, tom lane

In response to


pgsql-bugs by date

Next:From: SeattleServer.comDate: 2006-10-03 18:06:46
Subject: drop view stalled during pg_dump
Previous:From: Simon RiggsDate: 2006-10-03 17:38:36
Subject: Re: BUG #2671: incorrect return value by RULE

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group