From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: deprecating the use of OIDs |
Date: | 2003-09-29 22:37:12 |
Message-ID: | 11439.1064875032@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Neil Conway <neilc(at)samurai(dot)com> writes:
> (1) Add a GUC var, with a name such as "default_use_oids", defaulting to
> true. This controls whether a CREATE TABLE that doesn't include WITH or
> WITHOUT OIDS gets created with OIDs.
This I think was pretty noncontroversial.
> (2) When dumping a table, spit out a "SET default_use_oids = xxx" before
> the CREATE TABLE. This means that if a table was previously created WITH
> OIDS (either explicitly or by default), it will continue to have OIDs
> when the dump is restored (regardless of the default value of the GUC
> var). We could specify WITH or WITHOUT OIDS as part of the CREATE TABLE
> itself, but there were objections earlier about maintaining the
> cleanliness of the SQL produced by pg_dump:
It doesn't seem to me that this really buys much. What we really want
is a way for a dump/reload to remove OIDs from tables that formerly had
them; otherwise people will not easily be able to migrate their existing
tables away from having OIDs.
> ... and a single SET can apply to
> multiple CREATE TABLEs.
Not unless you want partial pg_restores to break.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2003-09-29 22:41:42 | Re: deprecating the use of OIDs |
Previous Message | Tom Lane | 2003-09-29 22:32:15 | Re: 7.4 status |