Re: [PATCH] Cleanup of GUC units code

From: "Marko Kreen" <markokr(at)gmail(dot)com>
To: "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] Cleanup of GUC units code
Date: 2008-09-03 09:18:33
Message-ID: e51f66da0809030218h27a0fdb0g3a4052f7e53bf0e5@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 9/3/08, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> Marko Kreen wrote:
> > On 9/2/08, Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Hannu Krosing 2008-09-03 09:23:58 Re: [PATCH] Cleanup of GUC units code
Previous Message Asko Oja 2008-09-03 08:58:18 Re: [PATCH] Cleanup of GUC units code