* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> I've been thinking more about this, and I think I'm about ready to
> change my position on it: why shouldn't we error out if the value
> is too small? If we believe that a GUC's unit is reasonably chosen,
> then it's not sensible to try to set the value to less than 1 unit.
Right, agreed.
> If the user tries then there's fairly good reason to assume that
> either it's a typo or he fundamentally doesn't understand the GUC.
> (This does not imply that he cares about the difference between
> 9999 and 9999.4 units.)
+1
> Or another way to say it is that if we had set the min_val to something
> positive, he'd have gotten a "value out of range" type of error.
> The only reason we don't do that, typically, is that we're allowing
> zero as a special case. Well, ok, let's allow zero as a special case,
> but it has to be written as "0" not something else. If you try to
> set a positive value then we should act as though the min_val is 1 unit.
Yes.
> So I'm coming around to the idea that "throw an error if a nonzero
> input would round (or truncate) to zero" is a reasonable solution.
> I think it'd be even more reasonable if we also fixed the rounding
> rule to be "round to nearest", but the two changes can be considered
> independently.
Agreed- they're independent considerations and the original concern was
about the nonzero-to-zero issue, so I'd suggest we address that first,
though in doing so we will need to consider what *actual* min values we
should have for some cases which currently allow going to zero for the
special case and that, I believe, makes this all 9.5 material and allows
us a bit more freedom in deciding how to hanlde things more generally.
As such, I'd also +1 the "round-to-nearest" suggestion as being quite
sensible too.
THanks,
Stephen