On Thu, 26 Sep 2002, Jan Wieck wrote:
> >>> But still, why set up a situation where your database might not
> >>> start? Why not set it up so that if you get just *one* environment
> >>> or command-line variable right, you can't set another inconsistently
> >>> and screw up your start anyway? Why store configuration information
> >>> outside of the database data directory in a form that's not easily
> >>> backed up, and not easily found by other utilities?
>
> Apply that argumentation to all of our commandline switches and config
> options and we end up with something that behaves like Microsoft
> products ... they know everything better, you cannot tune them, they
> work ... and you needed a bigger machine anyway.
Talk about a straw man! I have repeatedly said:
I WANT THE FEATURE THAT LETS YOU TUNE THE LOCATION OF THE LOG FILE!
Read it again, and again, until you understand that we both want
that feature.
Then realize, I just want it implemented in a way that makes it
less likely that people will find themselves in a situation where
the server doesn't start.
> I am absolutely not in favour of the PGXLOG environment variable. But if
> someone else wants it, it doesn't bother me because I wouldn't use it
> and it cannot hurt me.
Responsible programmers, when confronted with a more accident-prone
and less accident-prone way of doing something, chose the less
accident-prone way of doing things. That way people who are naive,
or tired, or just having a bad day are less likely to come to harm.
Using the config file is not only safer, it's actually more
convenient. And since we're going to have the config file option
anyway, removing the environment variable option means that others
have less documentation to read, and will spend less time wondering
why there's two different ways to do the same thing. And naive
people won't chose the wrong way because they don't know any better.
cjs
--
Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're
alllight. --XTC
