Re: more on initdb

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: more on initdb
Дата
Msg-id 3F8173D1.4010404@dunslane.net
обсуждение исходный текст
Ответ на Re: more on initdb  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: more on initdb  (Peter Eisentraut <peter_e@gmx.net>)
Re: more on initdb  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: more on initdb  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.net> writes:
>  
>
>>Is there any reason other than historical that the System Views setup 
>>isn't a separate script fed to postgres by initdb, like, say, the 
>>information schema file? If there isn't a good reason should we unwire 
>>it as part of moving to a C version of initdb?
>>    
>>
>
>Just historical, and go for it.
>
>  
>
I might. :-) Actually, it has struck me that the way we go about doing 
initdb is kinda hokey, again probably for historic reasons, and that if 
it were being redesigned from scratch today a better way would be to 
have an cluster image built at compile time and just copied and tweaked 
at runtime. Almost all the required info appears to be known at compile 
time, AFAICS. I assume we don't expect people to hack the input files 
like postgres.bki or information_schema.sql.

My aim has been to get something that will enable a complete Windows 
build (i.e. no shell or other external reliance) when the fork/signal 
problems on Windows are solved, and I think I am already at that point, 
at least as far as my testing has been able to go - the proof of the 
pudding will be in the eating. So making a change like I suggested above 
would be a longer term issue. I guess it ain't broke so it doesn't need 
to be fixed, so I'm not sure if it would be worth it.

Thoughts?

cheers

andrew



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jan Wieck
Дата:
Сообщение: Re: Open 7.4 items
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Missing error condition in CREATE TABLE