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