Re: [PATCH] Cleanup of GUC units code - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] Cleanup of GUC units code
Date
Msg-id 11001.1221006528@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] Cleanup of GUC units code  (Greg Smith <gsmith@gregsmith.com>)
Responses Re: [PATCH] Cleanup of GUC units code  (Greg Smith <gsmith@gregsmith.com>)
List pgsql-hackers
Greg Smith <gsmith@gregsmith.com> writes:
> What I would like to see (but don't 
> have nearly enough time to argue in support of considering the resistance 
> to change here) is that this syntax:

> shared_buffers=1024

> Would assume the user meant 1024 *bytes*, with the server silently 
> rounding that up to the nearest 8k block.  Then the whole issue of "do 
> they mean bits or bytes?" goes away, because no one would ever have to 
> include the "B".

How do you come to that conclusion?  Leaving off the unit entirely
certainly doesn't make the user's intent clearer.

There's also a pretty serious compatibility problem, which is that
settings that had always worked before would suddenly be completely
broken (off by a factor of 8192 qualifies as "broken" in my book).

I think that if we wanted to change anything here, we'd have to
*require* a unit spec on unit-affected parameters, at least for a period
of several releases.  Otherwise the confusion would be horrendous.

> That paves the way for making it easy to support 
> case-insensitive values without pedantic confusion.

Again, you're just making this up.  It doesn't make anything clearer.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Gregory Williamson"
Date:
Subject: Re: Keeping creation time of objects
Next
From: "Alex Hunsaker"
Date:
Subject: Re: [PATCHES] to_date() validation