forgot the list... On Thu, Jun 12, 2014 at 2:05 PM, David Johnston <david.g.johns...@gmail.com> wrote:
> On Thu, Jun 12, 2014 at 1:25 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> David Johnston <david.g.johns...@gmail.com> writes: >> > On Thursday, June 12, 2014, Tom Lane <t...@sss.pgh.pa.us> wrote: >> >> I don't think that argument holds water either. We routinely make >> >> changes that break old postgresql.conf files. Not in minor updates >> >> of course, but none of this is material for back-patching. >> >> > Then I'd pick throwing an error if a floating point value is assigned >> to a >> > parameter that is defined to accept integer. I'd rather actually break >> the >> > file and not silently redefine its contents. >> >> The case that was under discussion here had nothing to do with float vs >> integer: it was about rounding a time-interval value to the precision >> chosen for the underlying variable. > > > I get that: if I request "30s" I get a result of 0.5 - which is then > truncated to zero; "90s" = 1.5 -> 1 > > That is, if you write "10s" for >> a variable that's stored in minutes, what should you get? > > > 0.166667 > > >> I doubt that >> "an error" is the best answer here > > > If we cannot honor the exact value requested telling that to the user is > definitely a valid outcome > > >> --- one of the purposes of the units >> system for GUCs was to avoid people having to pay close attention to >> exactly what the measurement unit of each GUC is. > > > And if their desired value falls into the expected range of allowed > values then they can remain oblivious. But if they want to do something > that the system is incapable of supporting forcing them to explicitly chose > a different value is just as valid a decision as picking one for them. > > Restricting that to scaling up - which is what happens in reality anyway > - means that at least whatever the user tells the system is either what > they get or they are told their request is invalid. > > The likelihood of someone requesting "120s" when they desire "2m" is > unlikely - I would think that most typically they would be requesting a > number of, in this case, seconds that are less than the default unit, 1 > minute in this case. > > If it only errors when the final result is zero I would not be overly > opposed to situations like "90s" rounding to "2m" instead of "1m". > > >> So the realistic >> answers are "zero minutes" or "1 minute"; and if "zero minutes" is a >> special case then there's considerable merit in making the value go to >> "1 minute" instead. >> > > Another supporting argument is that the risk profile for anyone depending > on a non-explicit zero to obtain zero behavior is small - if they changed > from default and were checking to make sure the final result matched their > expectation they would see the relevant difference. The OP complaint > indeed is "I thought I enabled this but it didn't work". > > I am somewhat concerned about, say "100m" rounding to 2 hours instead of 1 > hour. The minute/second rounding is fairly small but for larger unit-pairs > the amount of delta before and after can be considerable. But there may be > few, if any, parameters that could be so affected so probably a moot > concern. > > >> Note that right at the moment the behavior is "round down", ie you get >> zero not 1 minute even if you wrote "59s". I claim that's definitely >> surprising. >> >> > As is rounding "70s" up to "2m" > > In both cases since we are taking invalid data and substituting valid data > we have to document what is being done. Its just the probability of > someone realizing and caring about what we are doing is smaller if we use > ceiling instead of floor. > > While I am generally in favor of requiring explicitness there is minimal > downside risk in leaving "implicit casting" of the data in this context. > Given that conclusion, making the change to ceiling from floor makes sense > - making it possible to only achieve zero explicitly is worthwhile. For all > non-zero situations the direction of rounding is largely immaterial if you > accept that rounding has value. > > David J. > >
