Re: OIDs as keys - Mailing list pgsql-performance

From Bruce Momjian
Subject Re: OIDs as keys
Date
Msg-id 200303062111.h26LB5J03462@candle.pha.pa.us
Whole thread Raw
In response to Re: OIDs as keys  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: OIDs as keys  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
Tom Lane wrote:
> "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.

Why was the schema path called search_path rather than schema_path?
Standards?

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

pgsql-performance by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Index File growing big.
Next
From: Bruce Momjian
Date:
Subject: Re: OIDs as keys