Re: Bootstrap DATA is a pita - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: Bootstrap DATA is a pita
Date
Msg-id 8EE5BCEC-235B-43D8-B066-887E418DD81A@gmail.com
Whole thread Raw
In response to Re: Bootstrap DATA is a pita  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Bootstrap DATA is a pita  (Caleb Welton <cwelton@pivotal.io>)
Re: Bootstrap DATA is a pita  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> On Dec 11, 2015, at 2:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Mark Dilger <hornschnorter@gmail.com> writes:
>>> On Dec 11, 2015, at 1:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> That's an interesting proposal.  It would mean that the catalog files
>>> stay at more or less their current semantic level (direct representations
>>> of bootstrap catalog contents), but it does sound like a more attractive
>>> way to perform complex edits than writing Emacs macros ;-).
>
>> I would be happy to work on this, if there is much chance of the community
>> accepting a patch.  Do you think replacing the numeric Oids for functions,
>> operators, opclasses and such in the source files with their names would
>> be ok, with the SQL converting those to Oids in the output?
>
> Huh?  Those files are the definition of that mapping, no?  Isn't what
> you're proposing circular?

No, there are far more references to Oids than there are definitions of them.

For example, the line in pg_operator.h:

DATA(insert OID =  15 ( "="        PGNSP PGUID b t t    23  20  16 416  36 int48eq eqsel eqjoinsel ));

defines 15 as the oid for the equals operator for (int8,int4) returning bool, but the
fact that 23 is the Oid for int4, 20 is the Oid for int8, and 16 is the Oid for bool
is already defined elsewhere (int pg_type.h) and need not be duplicated here.

I'm just proposing that we don't keep specifying things by number everywhere.
Once you've established the Oid for something (operator, type, function) you
should use the name everywhere else.

mark


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Using quicksort for every external sort run
Next
From: Greg Stark
Date:
Subject: Re: Using quicksort for every external sort run