At 19:35 2/11/00 -0500, Tom Lane wrote:
>We've hacked up pg_dump so that it won't dump objects inherited from
>template1. Unfortunately I have realized there are a couple of serious
>problems:
>
>1. What if the inherited object is a table or a sequence?
>2. For that matter, even function definitions might change
The only solution I can think of for this would be to use lastsysoid from
template1; this is the value set when initdb runs.
>3. What if the OID counter wraps around?
Can the code that wraps the OID restart it at 'select max(lastsysoid) from
pg_database'? Is that too complex?
>Maybe we should give up the whole idea of user data
>in template1.
I'm leaning a little this way, but local mods are useful.
There's also a problem if a db drops a function created by template1, then
creates its own version (eg. via (mythical) ALTER FUNCTION). If we restore
template1 then the db, we get a problem.
Perhaps, for pg_dumpall:
1. Restore vanilla template1 (this is probably not necessary?)
2. Restore all DBs (dumped using template1->lastsysoid)
3. Restore local mods to template1
And for single-db dump we dump using db->lastsysoid (the assumption being
that the DB will be restored in the 'right' template1 context). This would
be the default behaviour of pg_dump.
This requires a way of asking pg_dump to use a 'system' (ie. template1) or
'local' (ie. from the specific database) lastsysoid...( --last-oid
{S,D}/-L{S,D}). I think this fixes it, but perhaps I'm hallucinating.
Does this sound OK?
----------------------------------------------------------------
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 |/
