Re: Re: pg_dump tries to do too much per query
От | Philip Warner |
---|---|
Тема | Re: Re: pg_dump tries to do too much per query |
Дата | |
Msg-id | 3.0.5.32.20000920110552.0099f510@mail.rhyme.com.au обсуждение исходный текст |
Ответ на | Re: Re: pg_dump tries to do too much per query (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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 |/
В списке pgsql-hackers по дате отправления: