>> Why? What benefit do we get out of denying users this option? > > Why should we continue to support historical special case? It is not > a feature that adds anything to user experience with Postgres. > > Anyway, that was my vote only. If there are developers interested > in supporting oids feel free to do so. > > But now that I learned that ALTER TABLE WITHOUT OIDS either causes bugs > or requires table rewrite, it turned from minor annoyance to big annoyance. > So I'd like have a reasonable path for getting rid of them, which we don't > have currently. Removing them completely is simplest path, but adding > extra features to support it is another.
Well, see Tom's point upthread: OIDs are extensively used for system tables, and are not going away. So this is a pipe dream. In the meantime, ALTER TABLE WITHOUT OIDS is (at least for some people) an easier migration path than dump+reload. >> That might be true in your environment, but is certainly not true in >> general. We have many DDL commands that require full-table rewrites, and >> they are FAR from useless. > > Compared to not having the DDL commands or having DDL commands that > do not rewrite the tables? ;) Not having them, of course. If we remove ALTER TABLE WITHOUT OIDS, it's going to encourage people to do stuff like this: CREATE TABLE blah_without_oids AS SELECT * FROM blah; ALTER TABLE blah ... ALTER TABLE blah ... -- move foreign keys, constraints, etc. DROP TABLE blah; ALTER TABLE blah_without_oids RENAME TO blah; ...or else dump+reload. ISTM that if anything that's going to encourage people to keep the OIDs in there because it's too much work to get rid of them. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
