On Wed, 3 Sep 2008, Tom Lane wrote:
Greg Smith <[EMAIL PROTECTED]> writes:
First question--how about if I changed that description to read:
"Default value used at server startup if the parameter is not explicitly
set"?
"... not otherwise set" would probably be an accurate phrasing.
(I'm thinking of corner cases like stuff absorbed from environment
variables, which aren't really "explicitly" set by any normal usage
of that term.)
My opinion is that setting something in an environment variable certainly
is explicitly setting it, but it doesn't matter; "if the parameter is not
otherwise set" works just as well as far as I'm concerned.
I could then expose reset-val, named like that and with a description that
explained the context it applies in. And then we've give people a way to
experiment and understand the FAQ of "why didn't the value go back to the
default...
You do know that's an ex-FAQ as of 8.3? If we're designing this feature
to respond to that, we are wasting a lot of effort.
Sure, but there are a lot of pre-8.3 installs out there. I don't really
care about the reset-val at all, so I'm not going to justify whether or
not it should be included.
I wonder how certain you can be of which meaning of "default" they have
in mind. I don't think it means the same thing to everybody that it
means to you.
When most people say "the default" talking about a value in a
configuration file, they mean the value the software will assume if that
setting isn't there at all. In the postgresql.conf context, that means
what they'll get if they start the server with that line missing or
commented out (and no environment variables, etc.) which is why I mapped
that to the boot_val. While I'm aware there are other uses of "default"
that apply in this context, I think they are extremely rare compared to
the common usage. The subtle distictions that require both a boot_val and
a reset_val internally are only important to people who are also capable
of understanding that "default" is a mass-consumption oriented label
that's a touch fuzzy IMHO.
--
* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
