| From: | "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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:19:33 |
| Message-ID: | 044801c2de30$93d71ca0$6500a8c0@fhp.internal |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
> Right. But the problem with switching the OID default is not a matter
> of code --- it's of working out what the compatibility issues are.
> 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?!
> What we need is an agreement on the behavior we want (making
> the best possible compromise between this and other compatibility
> desires). After that, the actual patch is probably trivial, while in
> advance of some consensus on the behavior, offering a patch is a waste
> of time.
Sure.
Chris
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2003-02-27 07:30:43 | Re: OIDs as keys |
| Previous Message | Tom Lane | 2003-02-27 07:06:08 | Re: OIDs as keys |