On 9/3/08, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote:
> Marko Kreen wrote:
> > 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?
> >
>
> I doesn't seem completely unreasonable to me that we'd want to express
> something in megabits/second in the future. For example, instead of
> vacuum_cost_delay, it would be cool to specify a bandwidth allowance.
> Megabits/second is a completely reasonable unit for that. Or a limit on
> network bandwidth.
While it sounds theoretically useful, as a UI it's combines worst
from both worlds. You now can confuse user with both case-sensitivity
and unit-mixup. Even if we keep the current case-sensitivity, we should
set policy that units that differ only with case will never be accepted.
And the best way to set the policy in stone would be to make
units case-insensitive.
I like Asko's proposal of 'kbit/s' and 'mbit/s' for those - clear
and no chance of confusion.
> FWIW, I don't feel very strongly either way. I'm more than happy with the
> status quo. The hint in the error message very clearly spells out what the
> valid values are, so it's immediately clear what you need to fix if you get
> that wrong.
Well, the problem is that while database may come up with wrong values,
it may be unusable for actual loads, until admin browses the logs,
re-edits the config file and finally restarts in again.
--
marko
