From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, 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-03-06 21:11:05 |
Message-ID: | 200303062111.h26LB5J03462@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Tom Lane wrote:
> "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.
Why was the schema path called search_path rather than schema_path?
Standards?
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2003-03-06 21:13:12 | Re: OIDs as keys |
Previous Message | Bruce Momjian | 2003-03-06 20:18:56 | Re: Index File growing big. |