On Mon, Feb 13, 2012 at 8:51 AM, Marti Raudsepp <ma...@juffo.org> wrote: > On Mon, Feb 13, 2012 at 15:08, Robert Haas <robertmh...@gmail.com> wrote: >> Honestly, I think the biggest hassle of the OID code is not so much >> the way they're generated as the way they're stored within heap >> tuples. I've wondered whether we should go through the system >> catalogs and replace all of the hidden OID columns with a normal >> column called "oid" of type OID > > Do we have a clear idea about what to do with user tables that are > created WITH OIDS? Do we care about compatibility with that at all?
I think it would be fine to eventually drop support for user tables with OIDs. That hasn't been enabled by default for a very long time: commit 7ce9b7c0d8c8dbefc04978765422f760dcf3788c Author: Bruce Momjian <br...@momjian.us> Date: Mon Dec 1 22:08:02 2003 +0000 This patch adds a new GUC var, "default_with_oids", which follows the proposal for eventually deprecating OIDs on user tables that I posted earlier to pgsql-hackers. pg_dump now always specifies WITH OIDS or WITHOUT OIDS when dumping a table. The documentation has been updated. Neil Conway I think there's not much benefit to deprecating that feature as long as we need system OID columns in the catalogs. But if we got rid of them there then I think we could drop support in userland, too. > Do > we generate this explicit "oid" column manually or do we just tell > users to use a serial or global sequence instead? > > Personally I'd also like to see us get rid of the default_with_oids > setting -- I assume the existence of that is the reason why pgAdmin > and TOAD still generate table DDL with an explicit "WITH (OIDS=FALSE)" That probably has as much to do with inertia as anything else. I agree that it's ugly. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers