Re: Bug in PL/pgSQL GET DIAGNOSTICS? - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Bug in PL/pgSQL GET DIAGNOSTICS?
Date
Msg-id 200209262230.g8QMUrv13994@candle.pha.pa.us
Whole thread Raw
In response to Re: Bug in PL/pgSQL GET DIAGNOSTICS?  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Bug in PL/pgSQL GET DIAGNOSTICS?  (Peter Eisentraut <peter_e@gmx.net>)
List 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@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: Tom Lane
Date:
Subject: Re: Reconstructing FKs in pg_dump
Next
From: Stephan Szabo
Date:
Subject: Re: Reconstructing FKs in pg_dump