deprecating the use of OIDs
От | Neil Conway |
---|---|
Тема | deprecating the use of OIDs |
Дата | |
Msg-id | 1064870879.22498.23.camel@tokyo обсуждение исходный текст |
Ответы |
Re: deprecating the use of OIDs
Re: deprecating the use of OIDs |
Список | pgsql-hackers |
I think most people on this list will agree that having OIDs on user tables is a Bad Thing. For some previous discussion of why, see: http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg27374.html My understanding of the conclusion of previous discussions on this topic is that getting rid of OIDs on user tables eventually would be good, but there is some disagreement / confusion on how exactly to manage the transition. I think we should do the following for 7.5: (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. (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: if the OID-ness of the table is specified via a separate statement, it is easier for people porting the SQL to another DBMS to workaround, and a single SET can apply to multiple CREATE TABLEs. (2a) We could also add pg_dump options to control this behavior, if people like. (3) Add a comment in the release notes saying: (a) the use of OIDs for user tables is considered a deprecated feature (b) for compatibility with future versions of PostgreSQL, admins can try setting the GUC var to false, so they know which (if any) of their apps actually depend upon the use of OIDS. (4) In some future release of PostgreSQL (say, 7.6), toggle the GUC var to false by default. Objections, comments, etc. are welcome. -Neil P.S. It would be nice if we could get this done by 7.4, so as not to miss a whole release cycle, but that seems out of the question, unfortunately.
В списке pgsql-hackers по дате отправления: