Re: WIP: fix SET WITHOUT OIDS, add SET WITH OIDS
От | Tom Lane |
---|---|
Тема | Re: WIP: fix SET WITHOUT OIDS, add SET WITH OIDS |
Дата | |
Msg-id | 24126.1234121220@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: WIP: fix SET WITHOUT OIDS, add SET WITH OIDS (Zdenek Kotala <Zdenek.Kotala@Sun.COM>) |
Список | pgsql-hackers |
Zdenek Kotala <Zdenek.Kotala@Sun.COM> writes: > Tom Lane píše v ne 08. 02. 2009 v 11:51 -0500: >> Now, if you want to argue that we should get rid of SET WITHOUT OIDS >> altogether, I'm not sure I could dispute it. But if we have the >> ability to do that ISTM we should offer the reverse too. > By my opinion TABLES with OIDs is obsolete feature. It make sense to > have SET WITHOUT OIDS, because it is useful when people will migrate > form 7.4 to 8.4. But opposite way does not make me sense, because I > think we want to remove OID TABLES in the future. I personally prefer to > say that 8.4 is last version which supports CREATE TABLE ... WITH OIDS. If we're going to do that we should do it *now*, not later, because right now is when we have a bug that we could actually save some effort on. In practice, since we have not ever suggested that we were actually going to remove the feature, I don't believe that we can do that. Not in 8.4, and not in 8.5 or any other near-future release either. The larger point though is that unless we restructure the system to the point of not using OIDs in system catalogs ... which ain't happening ... the amount of code we could save by removing OIDs for users is vanishingly small. Probably on the rough order of 100 lines, and about the same in documentation. (We couldn't, for instances, stop documenting that OIDs exist.) Doesn't really seem worth breaking applications for, even deprecated ones. regards, tom lane
В списке pgsql-hackers по дате отправления: