Re: Re: pg_dump tries to do too much per query

Philip Warner <pjw@rhyme.com.au> writes:
>>> The reason that changing pg_dump is a superior solution for this problem
>>> is that there's only one place to change, not umpteen dozen ...
>> 
>> Well at least two, unless you like the following:
>> 
>> zzz=# select * from pg_views;
>> ERROR:  cache lookup of attribute 1 in relation 3450464 failed

> Apologies - I just noticed you fixed this in CVS, so it now manages
> (somehow!) to output a valid view definition even without the underlying
> table. A little scary, though.

Say what?  (... tries it ...)  Fascinating.  I wouldn't rely on this
behavior however; the fact that it works today is a totally unintended
consequence of a change I made for column alias support.  Next week
ruleutils.c might try to access the underlying tables again.

The general issue still remains: if a database contains an inconsistency
or error, introduced by whatever means (and there'll always be bugs),
a pg_dump failure is likely to be the first notice a dbadmin has about it.
So it behooves us to make sure that pg_dump issues error messages that
are as specific as possible.  In particular, if there is a specific
object such as a view or rule that's broken, pg_dump should take care
that it can finger that particular object, not have to report a generic
"SELECT failed" error message.

This problem has been around for a long time, of course, but now that
we have someone who's taking an active interest in fixing pg_dump ;-)
I'm hoping something will get done about it...
        regards, tom lane