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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to