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:
http://www.postgresql.org/mailpref/pgsql-hackers
