Stephen Frost <sfrost@snowman.net> writes:
> * Andrew Dunstan (andrew@dunslane.net) wrote:
>> On 03/07/2015 05:46 PM, Andres Freund wrote:
>>> On 2015-03-07 16:43:15 -0600, Jim Nasby wrote:
>>>> Semi-related... if we put some special handling in some places for bootstrap
>>>> mode, couldn't most catalog objects be created using SQL, once we got
>>>> pg_class, pg_attributes and pg_type created?
>>> Several people have now made that suggestion, but I *seriously* doubt
>>> that we actually want to go there. The overhead of executing SQL
>>> commands in comparison to the bki stuff is really rather
>>> noticeable. Doing the majority of the large number of insertions via SQL
>>> will make initdb noticeably slower. And it's already annoyingly
>>> slow. Besides make install it's probably the thing I wait most for
>>> during development.
>> My reaction exactly. We should not make users pay a price for
>> developers' convenience.
Another reason not to do this is that it would require a significant (in
my judgment) amount of crapification of a lot of code with bootstrap-mode
special cases. Neither the parser, the planner, nor the executor could
function in bootstrap mode without a lot of lobotomization. Far better
to confine all that ugliness to bootstrap.c.
> Just to clarify, since Jim was responding to my comment, my thought was
> *not* to use SQL commands inside initdb, but rather to use PG to create
> the source files that we have today in our tree, which wouldn't slow
> down initdb at all.
That, on the other hand, might be a sane suggestion. I'm not sure
though. It feels more like "use the hammer you have at hand" than
necessarily being a good fit. In particular, keeping the raw data in
some tables doesn't seem like an environment that would naturally
distinguish between hard-coded and defaultable values. For instance,
how would you distinguish hard-coded OIDs from ones that could be
assigned at initdb's whim?
regards, tom lane