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

At 12:13 19/09/00 -0400, Tom Lane wrote:
>
>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.

In this particular instance, I'd still be much happier to see the code that
fails identify itself properly, identify the cause, and explain the error.
In the case in point, all of this information is available. I always prefer
to fix two bugs with one code change where possible (ie. 'select * from
pg_views' as well as pg_dump).

To carry this to extremes, at one point pg_dump crosses pg_index, pg_class
and pg_am somewhere else it crosses pg_rewrite, pg_class, and pg_rules etc.

If we want to allow for database corruption, pg_dump should really be doing
this sort of cross internally to verify that each part is present (or use
LOJ, and test for NULLs - but you hinted that there was a problem with this).

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

Part of my interest in pg_dump is in trying to make it know less about the
database structure, and so make it a lot more independant of versions. If I
could use one pg_* view or function for each entity type, I'd be very
happy. The not-so-recent discussions about definition schemas should
indicate where pg_dump wants to go, and the growing use of functions like
'format_type' make it increasingly hard to know why an error occurred - I
haven't looked to see what format_type does when it encounters an internal
inconsistency, but I hope it returns NULL.

[Thought: What would be the impact of pg_get_ruledef etc returning NULL
when it can't find the relevant data? This sort of approach seems to me
more consistent with DB-ish things, and pg_dump could easily test for a
NULL defn of a view relation]

I'd prefer to see a 'pg_verify' (or similar). The idea being that it would
know about and be totally anal about interrelationships - and successfully
report a missing view table - unlike the current (or proposed) situation.
In some ways, like a vacuum, but on metadata.

I'm not toally opposed to your suggestion, and I certainly agree that
making pg_dump more carefull about the data it retrieves is a good idea.
But I still need more convincing about the calls to get_viewdef.

In the current situation, I think ruleutils.c might need to be looked at
more closely: eg. several error messages prepend the main routine name,
some do not. Some display the problem rule name, other do not. There are
only three or four external routines defined, so by using (more) globals it
is easily possible for all routines to indicate the primary routine
responsible. Similarly, the rule/view name is already a global, and is
available to all routines in ruleutils.c.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/