Re: Bug in PL/pgSQL GET DIAGNOSTICS?

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Michael Paesold <mpaesold(at)gmx(dot)at>, PostgreSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bug in PL/pgSQL GET DIAGNOSTICS?
Date: 2002-09-26 22:30:53
Message-ID: 200209262230.g8QMUrv13994@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > To summarize, with non-INSTEAD, we get the tag, oid, and tuple count of
> > the original query. Everyone agrees on that.
> >
> > For non-INSTEAD, we have:
>
> [I think this is the INSTEAD part.]

Sorry, yes.

> > 1) return original tag
> > 2) return oid if all inserts in the rule insert only one row
> > 3) return tuple count of all commands with the same tag
>
> I think proper encapsulation would require us to simulate the original
> command, hiding the fact that something else happened internally. I know
> it's really hard to determine the "virtual" count of an update or delete
> if the command had acted on a permament base table, but I'd rather
> maintain the encapsulation of updateable views and return "unknown" in
> that case.

Well, let's look at the common case. For proper view rules, these would
all return the right values because the UPDATE in the rule would be
returned. Is that what you mean?

--
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephan Szabo 2002-09-26 22:44:43 Re: Reconstructing FKs in pg_dump
Previous Message Peter Eisentraut 2002-09-26 22:28:18 Re: AIX compilation problems (was Re: Proposal ...)