On 9/3/08, Heikki Linnakangas <[EMAIL PROTECTED]> wrote: > Marko Kreen wrote: > > On 9/2/08, Peter Eisentraut <[EMAIL PROTECTED]> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
