Re: Unhappy thoughts about pg_dump and objects inherited from template1

At 20:12 2/11/00 -0500, Tom Lane wrote:
>Philip Warner <pjw@rhyme.com.au> writes:
>>> 1. What if the inherited object is a table or a sequence?
>
>> The only solution I can think of for this would be to use lastsysoid from
>> template1; this is the value set when initdb runs.
>
>How does that help?  It won't tell you anything about updated or deleted
>rows, nor about sequence advances, nor ALTER FUNCTION changes.  You
>could detect inserted rows, and that's about it.

In template1, lastsysoid is based on entries in pg_description. So it is
very close to restoring the original behaviour of pg_dump. I agree it won't
fix everything, but it will ensure it is no worse than before.

In the longer term, OID wrapping will be a problem for *any* oid-based
restoration scheme, as will ALTER FUNCTION. This is true for old & new
pg_dump alike.

The only real solution is to go away from OID-based restore, but I can't
see how. An 'add-or-update' method of restoration for everything, including
system tables, would be a disaster for version upgrades.

Any suggestions?


>> Can the code that wraps the OID restart it at 'select max(lastsysoid) from
>> pg_database'? Is that too complex?
>
>(the OID allocator is way too low-level to go off
>invoking arbitrary queries with safety).

Thought that might be the case :-(


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