On Sun, Jul 26, 2009 at 5:48 PM, Tom Lane<tgl@sss.pgh.pa.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
