Stephen Frost <sfr...@snowman.net> writes:
> * Tomonari Katsumata (t.katsumata1...@gmail.com) wrote:
>> I'm thinking about a method which users get quick awareness it.
>> Now, it's okay not to change current behavior except non-zero value yields
>> a zero. A zero rounded down from non-zero gets an error.
> In general, I'm a fan of this change and will move forward with it,
> with changes for the above, unless folks object. Based on the thread so
> far, this sounds like the right solution and it'd be great to get this
> simple change done to help move the CF along.
Hm, I object to a patch that behaves as stated above. I'm okay with
silently rounding *up* to the lowest possible nonzero value, eg rounding
up 7kB to 8kB if the variable's unit is 8kB. But if we throw an error for
7kB and not 8kB, then we are exposing the unit size in a way that the user
can't ignore. That seems to me to be antithetical to the entire design
rationale for GUC units. More, it doesn't fix the original complaint here,
which is that the user would be surprised if he specifies 7kB and gets
some special behavior instead because it's "too close to zero but not
exactly zero". 7kB should act as though it's not zero. If the difference
between 7kB and 8kB is actually user-meaningful, then we chose too coarse
a unit for the particular GUC, which is not something that a rounding rule
can paper over. But the difference between zero and not-zero is
meaningful regardless of unit choices.
This argument doesn't say anything much about which way to round for
values that are fractional but larger than the unit size. I'd probably
prefer a "round away from zero" behavior since that seems to be the most
consistent rule if we want to avoid silently creating zero values; but
I could be talked into something else.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
