Re: Bug in PL/pgSQL GET DIAGNOSTICS?

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Bug in PL/pgSQL GET DIAGNOSTICS?
Дата
Msg-id 200209262230.g8QMUrv13994@candle.pha.pa.us
обсуждение исходный текст
Ответ на Re: Bug in PL/pgSQL GET DIAGNOSTICS?  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Bug in PL/pgSQL GET DIAGNOSTICS?  (Peter Eisentraut <peter_e@gmx.net>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Reconstructing FKs in pg_dump
Следующее
От: Stephan Szabo
Дата:
Сообщение: Re: Reconstructing FKs in pg_dump