
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?

cheers

andrew




Sun, 05 Oct 2003 17:24:18 -0400
Andrew Dunstan <andrew@dunslane.net>
more on initdb
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.

			regards, tom lane

PS: please don't send stuff bcc to pgsql-hackers.  I was fortunate to
notice this in my probable-spam folder before deleting it ...

Mon, 06 Oct 2003 00:50:19 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: more on initdb 


Tom Lane wrote:

>
>PS: please don't send stuff bcc to pgsql-hackers.  I was fortunate to
>notice this in my probable-spam folder before deleting it ...
>  
>

Yeah, that was a fat finger mistake.

cheers

andrew


Mon, 06 Oct 2003 05:27:18 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: more on initdb
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


Mon, 06 Oct 2003 09:53:21 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: more on initdb
Andrew Dunstan 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.

One of the constraints that would make this difficult is that during the
build process you cannot run the programs you just compiled, at least not
without opening a can of worms.

-- 
Peter Eisentraut   peter_e@gmx.net


Mon, 6 Oct 2003 16:25:35 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Re: more on initdb
Andrew Dunstan <andrew@dunslane.net> writes:
> 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.

That's about my feeling.  There's nothing wrong with the initdb process,
other than its dependency on shell scripting, and so no visible gain to
be had by reimplementing it further than replacing the shell script.

			regards, tom lane

Mon, 06 Oct 2003 12:05:29 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: more on initdb 
Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.net> writes:
>  
>
>>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.
>>    
>>
>
>That's about my feeling.  There's nothing wrong with the initdb process,
>other than its dependency on shell scripting, and so no visible gain to
>be had by reimplementing it further than replacing the shell script.
>
>  
>
OK, I'm happy enough with that - just throwing out ideas.

cheers

andrew


Mon, 06 Oct 2003 12:12:45 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: more on initdb
Andrew Dunstan <andrew@dunslane.net> writes:
> 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.

One thing we would rather not have to freeze at compile time is the
locale settings...

			regards, tom lane

Mon, 06 Oct 2003 12:19:32 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: more on initdb 
Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.net> writes:
>  
>
>>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.
>>    
>>
>
>One thing we would rather not have to freeze at compile time is the
>locale settings...
>
>  
>
That would have been one of the tweaks :-) Anyway, I'll let sleeping 
dogs lie.

cheers

andrew


Mon, 06 Oct 2003 12:27:06 -0400
Andrew Dunstan <andrew@dunslane.net>
Re: more on initdb