Re: [RFC] Removing "magic" oids

Hi,

On 2018-11-15 17:25:21 +0700, John Naylor wrote:
> 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.

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