Re: [RFC] Removing "magic" oids - Mailing list pgsql-hackers

From Andreas Karlsson
Subject Re: [RFC] Removing "magic" oids
Date
Msg-id fc8f0f5c-5b69-94af-1b03-ebcdf37b46d5@proxel.se
Whole thread Raw
In response to [RFC] Removing "magic" oids  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 09/30/2018 05:48 AM, Andres Freund wrote:> I think we should drop 
WITH OIDs support.

+1

> 2) We need to be able to manually insert into catalog tables. Both
>     initdb and emergency surgery.  My current hack is doing so directly
>     in nodeModifyTable.c but that's beyond ugly.  I think we should add
>     an explicit DEFAULT clause to those columns with something like
>     nextoid('tablename', 'name_of_index') or such.

Adding a function to get the next OID sounds like a good solution for 
both our catalog and legacy applications. The only potential 
disadvantage that I see is that this function becomes something we need 
to maintain if we ever decide to move from OIDs to sequences.

> 3) The quickest way to deal with the bootstrap code was to just assign
>     all oids for oid carrying tables that don't yet have any assigned.
>     That doesn't generally seem terrible, although it's certainly badly
>     implemented right now.  That'd mean we'd have three ranges of oids
>     probably, unless we somehow have the bootstrap code advance the
>     in-database oid counter to a right state before we start with
>     post-bootstrap work.  I like the idea of all bootstrap time oids
>     being determined by genbki.pl (I think that'll allow to remove some
>     code too).

Agreed, having genbki.pl determine all oids in the bootstrap data sounds 
ideal.

Andreas



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Performance improvements for src/port/snprintf.c
Next
From: Dean Rasheed
Date:
Subject: Re: BUG #15307: Low numerical precision of (Co-) Variance