On Sun, Jul 26, 2009 at 5:48 PM, Tom Lane<t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers