Re: [PATCH] Cleanup of GUC units code

On 9/2/08, Peter Eisentraut <peter_e@gmx.net> wrote:
> Marko Kreen wrote:
> > In the meantime, here is simple patch for case-insensivity.
>
>  You might be able to talk me into accepting various unambiguous, common
> alternative spellings of various units.  But for instance allowing MB and Mb
> to mean the same thing is insane.

How would the docs for that look like?  And anyway, what is wrong with
Mb for megabytes?  mB may be slightly weird but if some user likes it,
I see no reason to reject it.

You do realize that misspelling unit name can cause downtime of several
minutes instead of couple seconds?  We can easily do restart in couple of
seconds but the restart, look logs, launch editor, find value, change,
save, restart cycle will take quite a lot more.  Why should we increase
the chance that any config edit causes problems?

Secondly, humans don't have byte-exact memory, instead they generalize
and deduce (eg. from nearby parameters).  Thus remembering "KB, MB, GB"
or "kb, mb, gb" is easier than remembering "kB, MB, GB".  Also remembering
"ms, s, m, h, d" is easier than "ms, s, min, h, d". (I'm not proposing 'm'
for minutes, just noting, that as we shouldn't ever introduce 'month' unit
for core config values, the 'm' as minutes is preferable for 'min'.)

Thirdly, please don't use "standard units" argument, unless you plan to
propose use of "KiB, MiB, GiB" at the same moment.  The units will be
remembered as units-for-postgresql.conf.  It is good if they conform to
user expectations, but it's even more important they are easy to remember.

Fourth, for the same reason, it is preferable the amount of units
accepted stays small.  Again, to be easily rememberable.  This
also kills any chance "mb" can be confused with "milli-bits".

If any extension/module wants to use any other units or full-SI,
it can but that should not extend to core config values.  Again,
to reduce chance for confusion.

So, are there any other arguments for keeping current behaviour?

-- 
marko