Re: Bootstrap DATA is a pita

From: Caleb Welton <cwelton(at)pivotal(dot)io>
To: Mark Dilger <hornschnorter(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Bootstrap DATA is a pita
Date: 2015-12-11 23:02:17
Message-ID: CAOjayEdA0J=QnDZR5br+AoQ+99bkzS=2SpYL3KwHyz6WCpZ-rg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Yes, that alone without any other changes would be a marked improvement and
could be implemented in many places, pg_operator is a good example.

... but there is some circularity especially with respect to type
definitions and the functions that define those types. If you changed the
definition of prorettype into a regtype then bootstrap would try to lookup
the type before the pg_type entry exists and throw a fit. That's handled
in SQL via shell types. If we wanted bootstrap to be able to handle this
then we'd have to make two passes of pg_type, the first to create the
shells and the second to handle populating the serialization functions.

Unfortunately types and functions tend to be the more volatile areas of the
catalog so this particular circularity is particularly vexing.

On Fri, Dec 11, 2015 at 2:53 PM, Mark Dilger <hornschnorter(at)gmail(dot)com>
wrote:

>
> > On Dec 11, 2015, at 2:40 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >
> > Mark Dilger <hornschnorter(at)gmail(dot)com> writes:
> >>> On Dec 11, 2015, at 1:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-12-11 23:02:57 Re: Bootstrap DATA is a pita
Previous Message Peter Geoghegan 2015-12-11 22:56:56 Re: Using quicksort for every external sort run