Andrew Dunstan <[EMAIL PROTECTED]> writes: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.
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.
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
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
