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

From John Naylor
Subject Re: [RFC] Removing "magic" oids
Date
Msg-id CAJVSVGVepnvnYN2TRufCa+dZ-JhVKGo77rtgO2frz1tj+wriHQ@mail.gmail.com
Whole thread Raw
In response to Re: [RFC] Removing "magic" oids  (Andres Freund <andres@anarazel.de>)
Responses Re: [RFC] Removing "magic" oids  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 11/15/18, Andres Freund <andres@anarazel.de> wrote:
> I've now revised this slightly. genbki.pl now computes the maximum oid
> explicitly assigned in .dat files, and assignes oids to all 'oid'
> columns without a value.  It does so starting directly at the maximum
> value.  I personally don't see need to have implicit .bki oids be in a
> different range, and having them assigned more densely is good for some
> things (e.g. the fmgr builtins table, even though we currently assign
> all proc oids manually).

I don't see an advantage to having a different range, but maybe it
should error out if $maxoid reaches FirstBootstrapObjectId.

This patch breaks reformat_dat_file.pl. I've attached a fix, which
also de-lists oid as a special key within the *.dat files. It might be
good to put off reformatting until feature freeze, so as not to break
others' patches.

-John Naylor

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: reloption to prevent VACUUM from truncating empty pages at theend of relation
Next
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] Transactions involving multiple postgres foreignservers, take 2