From: | Andreas Karlsson <andreas(at)proxel(dot)se> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [RFC] Removing "magic" oids |
Date: | 2018-10-03 12:34:49 |
Message-ID: | fc8f0f5c-5b69-94af-1b03-ebcdf37b46d5@proxel.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2018-10-03 13:04:45 | Re: BUG #15307: Low numerical precision of (Co-) Variance |
Previous Message | Tom Lane | 2018-10-03 12:20:14 | Re: Performance improvements for src/port/snprintf.c |