"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
>> As I recall, one thing people did not want was for pg_dump to plaster
>> WITH OIDS or WITHOUT OIDS on every single CREATE TABLE, as this would
>> pretty much destroy any shot at loading PG dumps into any other
>> database.
> Ummm...what about SERIAL columns, ALTER TABLE / SET STATS, SET STORAGE,
> custom types, 'btree' in CREATE INDEX, SET SEARCH_PATH, '::" cast operator,
> stored procedures, rules, etc. - how is adding WITH OIDS going to change
> that?!
It's moving in the wrong direction. We've been slowly eliminating
unnecessary nonstandardisms in pg_dump output; this puts in a new one
in a quite fundamental place. You could perhaps expect another DB
to drop commands it didn't understand like SET SEARCH_PATH ... but if
it drops all your CREATE TABLEs, you ain't got much dump left to load.
I'm not necessarily wedded to the above argument myself, mind you;
but it is a valid point that needs to be weighed in the balance of
what we're trying to accomplish.
The bottom line is that "code first, design later" is no way to
approach this problem.
regards, tom lane
