Re: proposal: rounding up time value less than its unit.

On 9/26/14, 2:17 PM, Tom Lane wrote:
> 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. 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 expressed some distaste for throwing errors before, but I find this 
specific rule reasonable.  I'll even write the patch.  I owe the GUC 
system a re-match after my wal_buffers auto-scaling thing for 9.1 
rippled to cause extra work for you (maybe Robert too).

I just changed this submission from "Ready for Committer" to "Returned 
with Feedback", with the feedback being that we'd like to see special 
values rounded to 0 treated differently altogether first, before 
touching any rounding.  And that's a whole new submission for the next CF.

> 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. regards, tom lane 

Personally I'm still -1 on any rounding change, instead preferring to 
work toward eliminating these 0 & -1 special values altogether.  Outside 
of these special cases, I feel you are fundamentally right that if the 
rounding really matters, the unit is simply too large.  And I believe 
that is the case for the log rotation one right now.

I can see my idea for rescaling the rotation age parameter is an 
unpopular one, but I still like it.  That cleanly splits out into a 
third thing though, where it can live or die without being tied to the 
rest of these issues.

-- 
Greg Smith greg.smith@crunchydatasolutions.com
Chief PostgreSQL Evangelist - http://crunchydatasolutions.com/