Skip site navigation (1) Skip section navigation (2)

Re: OIDs as keys

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
Cc: "daniel alvarez" <d-alvarez(at)gmx(dot)de>,"Richard Huxton" <dev(at)archonet(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: OIDs as keys
Date: 2003-02-27 07:30:43
Message-ID: 9227.1046331043@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
"Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)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

In response to

Responses

pgsql-performance by date

Next:From: Christopher Kings-LynneDate: 2003-02-27 09:03:37
Subject: Re: Index File growing big.
Previous:From: Christopher Kings-LynneDate: 2003-02-27 07:19:33
Subject: Re: OIDs as keys

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group