Re: autogenerating headers & bki stuff

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: autogenerating headers & bki stuff
Date: 2009-07-26 17:40:29
Message-ID: 407d949e0907261040l7d4be5d4he0af43f88b497fa4@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jul 26, 2009 at 5:48 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> In the spirit of not inventing single-purpose solutions, I suggest
> that the BKI representation for this might be something like
>
> BKI_EXECUTE( any old SQL command );
>
> where the bootstrap.c code just passes the given string to the main SQL
> parser, and whether it works or not is dependent on whether the
> specified command has been bootstrap-mode-proofed.  For the moment we'd
> only bother to fix CREATE OPERATOR CLASS/FAMILY to work that way, but
> the door would be open for other things if it seemed worthwhile.

I have nothing against a BKI_EXECUTE() like you propose.

But my instinct is still to go the other way. Of determining which
parts are actually necessary for bootstrapping and which parts really
aren't. I think it's valuable to have those two classes separated so
we understand when we're introducing new dependencies and when we're
varying from the well-trodden standard approaches.

It would also be valuable if we ever want to move some of these things
out to contrib modules or move other modules into the core. We might
even envision having optional components which the user could have the
optoin to decide at at initdb-time whether to include them.

AFAICT the only opclasses that need to be in the bootstrap set are
int2_ops, int4_ops, name_ops, oid_ops, and oidvector_ops.

--
greg
http://mit.edu/~gsstark/resume.pdf

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-07-26 17:43:19 Re: Review: support for multiplexing SIGUSR1
Previous Message Ron Mayer 2009-07-26 17:15:23 Re: SE-PostgreSQL Specifications