I wrote:
> ... So maybe we could split the current bootstrap phase
> into three phases:
> * create core catalogs and load DATA commands, using bki
> * create operator classes, using sql script
> * create indexes, using bki
> * proceed on as before
I experimented with that a little bit and found it doesn't seem to be
tremendously easy. A non-bootstrap-mode backend will PANIC immediately
on startup if it doesn't find the critical system indexes, so the second
step has issues. Also, there is no provision for resuming bootstrap
mode in an already-existing database, so the third step doesn't work
either. We could hack up solutions to those things, but it's not clear
that it's worth it. What seems more profitable is just to allow CREATE
OPERATOR CLASS/FAMILY to be executed while still in bootstrap mode.
There will still be some obstacles to be surmounted, no doubt (in
particular persuading these commands to run without system indexes
present) ... but we'd have to surmount those anyway.
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.
regards, tom lane
