Hi,
On 2018-11-15 17:25:21 +0700, John Naylor wrote:
> On 11/15/18, Andres Freund <and...@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.
Hm. Not sure I really see the point. Note we didn't have that check
before either, and it'd not catch manual assignment of too high oids. I
wonder if we should have a check in sanity_check.sql or such, that'd
then catch both?
> 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.
Thanks for catching that. I wonder if we could fix that in a way that
doesn't move oid into the middle of the data - while it's less magic-y
from a storage level, it's still more important than the rest. Perhaps
we could just leave oid in metadata and skip all @metadata elements in
format_hash()?
> @@ -193,7 +192,7 @@ sub strip_default_values
> {
> my $attname = $column->{name};
> die "strip_default_values: $catname.$attname undefined\n"
> - if !defined $row->{$attname};
> + if !defined $row->{$attname} and $attname ne 'oid';
>
> if (defined $column->{default}
> and ($row->{$attname} eq $column->{default}))
Hm, why is there no column definition for oid?
Greetings,
Andres Freund
