> So Andrews opinion was that Mb (meaning Mbit) is different from MB (for
> megabyte) and that if someone thinks that we define shared buffers in
> megabits can get confused and order wrong kind of network card ?
I know it's fun to point and laugh instead of giving an argument, but
the above is not what I said. What I said is that there is a
technical difference between at least some of these units, and one
that is relevant in some contexts where we have good reason to believe
Postgres is used. So it seems to me that there is at least a _prima
facie_ reason in favour of making case-based decisions. Your argument
against that appears to be, "Well, people can be sloppy."
Alvaro's suggestion seems to me to be a better one. It is customary,
in servers with large complicated configuration systems, for the
server to come with a tool that validates the configuration file
before you try to load it. Postfix does this; apache does it; so does
BIND. Heck, even NSD (which is way less configurable than BIND) does
this. Offering such a tool provides considerable more benefit than
the questionable one of allowing people to type whatever they want
into the configuration file and suppose that the server will by magic
know what they meant.
> I can understand Alvaros stance more readily - if we have irrational
> constraints on what can go into conf file, and people wont listen to
> reason
Extending your current reasoning, it's irrational that all the names
of the parameters have to be spelled correctly. Why can't we just
accept log_statement_duration_min? It's _obvious_ that it's the same
thing as log_min_duration_statement! It's silly to expect that
harried administrators have to spell these options correctly. Why
can't we parse all the file, separating each label by "_". Then if
any arrangements of those labels matches a "real" configuration
parameter, select that one as the thing to match and proceed from
there?
A
--
Andrew Sullivan
ajs@commandprompt.com
+1 503 667 4564 x104
http://www.commandprompt.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment