Martin Pitt <[EMAIL PROTECTED]> writes:
> Tom Lane [2006-02-18 13:32 -0500]:
>> Martin Pitt <[EMAIL PROTECTED]> writes:
>>> The core problem is that we want to not restore objects (mainly
>>> tables) in the destination database which already exist.
>>
>> Why is this a problem? It's already the default behavior --- the
>> creation commands fail but pg_restore keeps going.
> The problem is that pg_restore would restore the TABLE DATA object,
> although we don't want that (the postgis specific tables are
> pre-populated by PostGIS itself, and should not be altered by the
> upgrade.
Hm. Rather than a variant of the -L facility (which is hard to use,
and I don't see your proposal being much easier), maybe what's wanted
is just a flag saying "don't try to restore data into any table whose
creation command fails". Maybe that should even be the default ...
and you could extend it to indexes and constraints on such tables too,
as those would likely end up being duplicated as well.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
