Re: BUG #2671: incorrect return value by RULE

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 18:13:06
Message-ID: 1159899186.2659.320.camel@holly
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Tue, 2006-10-03 at 13:56 -0400, Tom Lane wrote:
> 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
> >> http://www.postgresql.org/docs/8.1/static/rules-status.html
>
> > 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.

Good point, and you make me feel better about ignoring that since.

Those thoughts inch forward the idea that partitions aren't quite on the
same level as full tables, even if they have many similarities.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Graham Davis 2006-10-03 18:20:49 Re: BUG #2658: Query not using index
Previous Message SeattleServer.com 2006-10-03 18:06:46 drop view stalled during pg_dump