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

On 9/26/14, 3:22 PM, Tom Lane wrote: We could alternatively try to split up these cases into multiple GUCs, which I guess is what you're imagining as a "multi-year battle". No, I was just pointing out that even the cleanest major refactoring possible here is going to result in broken config fi

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

On Friday, September 26, 2014, Alvaro Herrera wrote: > David Johnston wrote: > > On Friday, September 26, 2014, Alvaro Herrera > > > wrote: > > > > > Tom Lane wrote: > > > > > > > The impression I had was that Stephen was thinking of actually > setting > > > > min_val to 1 (or whatever) and hand

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

On 9/26/14, 2:50 PM, David G Johnston wrote: Like I said I just want to fix the bug and call it a day :) I'm afraid you've come to the wrong project and mailing list for *that*. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http

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

David Johnston wrote: > On Friday, September 26, 2014, Alvaro Herrera > wrote: > > > Tom Lane wrote: > > > > > The impression I had was that Stephen was thinking of actually setting > > > min_val to 1 (or whatever) and handling zero or -1 in some out-of-band > > > fashion, perhaps by adding GUC f

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

On Friday, September 26, 2014, Alvaro Herrera wrote: > Tom Lane wrote: > > > The impression I had was that Stephen was thinking of actually setting > > min_val to 1 (or whatever) and handling zero or -1 in some out-of-band > > fashion, perhaps by adding GUC flag bits showing those as allowable >

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

Tom Lane wrote: > The impression I had was that Stephen was thinking of actually setting > min_val to 1 (or whatever) and handling zero or -1 in some out-of-band > fashion, perhaps by adding GUC flag bits showing those as allowable > special cases. I'm not sure how we would display such a state o

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

* Tom Lane (t...@sss.pgh.pa.us) wrote: > > There are others where min_val is -1 for the same reason, where > > functionally the minimum is really 0. Some of us would like to see > > min_val reflect the useful minimum, period, and move all these special > > case ones out of there. That is a mul

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

Gregory Smith writes: > On 9/26/14, 2:34 PM, David Johnston wrote: >> ​ I don't get where we "need" to do anything else besides that...the >> whole "actual min values" comment is unclear to me. > If you look at pg_settings, there is a minimum value exposed there as > min_val. For some of the

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

On 9/26/14, 2:34 PM, David Johnston wrote: ​ I don't get where we "need" to do anything else besides that...the whole "actual min values" comment is unclear to me. If you look at pg_settings, there is a minimum value exposed there as min_val. For some of these parameters, that number would

Re: [HACKERS] 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

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

On 09/26/2014 11:17 AM, Tom Lane wrote: > 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

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

On Fri, Sep 26, 2014 at 2:39 PM, Stephen Frost [via PostgreSQL] < ml-node+s1045698n5820714...@n5.nabble.com> wrote: > David, > > * David Johnston ([hidden email] > ) wrote: > > ​This is 9.5 material because 1) it isn't all that critical and, 2)

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

David, * David Johnston (david.g.johns...@gmail.com) wrote: > ​This is 9.5 material because 1) it isn't all that critical and, 2) we DO > NOT want a system to not come up because of a GUC paring error after a > minor-release update. Agreed. > ​I don't get where we "need" to do anything else besi

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

On Fri, Sep 26, 2014 at 2:27 PM, Stephen Frost wrote: > > 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 so

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

Stephen Frost writes: > 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 goin

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

* Tom Lane (t...@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

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

On Fri, Sep 26, 2014 at 2:02 PM, Robert Haas wrote: > On Fri, Sep 26, 2014 at 1:22 PM, Tom Lane wrote: > > Robert Haas writes: > >> If we want the narrowest possible fix for this, I think it's "complain > >> if a non-zero value would round to zero". That fixes the original > >> complaint and c

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

David Johnston writes: > On Fri, Sep 26, 2014 at 1:22 PM, Tom Lane wrote: >> I apparently have got to make this point one more time: if the user >> cares about the difference between 30sec and 1min, then we erred in >> designing the GUC in question; it should have had a smaller unit. >> I am comp

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

On Fri, Sep 26, 2014 at 1:22 PM, Tom Lane wrote: > Robert Haas writes: >> If we want the narrowest possible fix for this, I think it's "complain >> if a non-zero value would round to zero". That fixes the original >> complaint and changes absolutely nothing else. But I think that's >> kind of w

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

On Fri, Sep 26, 2014 at 1:22 PM, Tom Lane wrote: > Robert Haas writes: > > If we want the narrowest possible fix for this, I think it's "complain > > if a non-zero value would round to zero". That fixes the original > > complaint and changes absolutely nothing else. But I think that's > > kind

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

* Josh Berkus (j...@agliodbs.com) wrote: > On 09/26/2014 10:27 AM, Stephen Frost wrote: > > I don't think anyone is argueing that we should do away with the > > rounding rules entirely, only that we should a) require units to be > > specified, and b) error if the value specified is below '1 unit',

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

On 09/26/2014 10:27 AM, Stephen Frost wrote: > I don't think anyone is argueing that we should do away with the > rounding rules entirely, only that we should a) require units to be > specified, and b) error if the value specified is below '1 unit', but > still non-zero, as it would then be rounded

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

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Robert Haas writes: > > If we want the narrowest possible fix for this, I think it's "complain > > if a non-zero value would round to zero". That fixes the original > > complaint and changes absolutely nothing else. But I think that's > > kind of wu

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

Robert Haas writes: > If we want the narrowest possible fix for this, I think it's "complain > if a non-zero value would round to zero". That fixes the original > complaint and changes absolutely nothing else. But I think that's > kind of wussy. Yeah, rounding 29 seconds down to a special magic

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

On Fri, Sep 26, 2014 at 10:58 AM, Stephen Frost wrote: > * Robert Haas (robertmh...@gmail.com) wrote: >> On Thu, Sep 25, 2014 at 4:49 PM, Stephen Frost wrote: >> > * Gregory Smith (gregsmithpg...@gmail.com) wrote: >> >> On 9/25/14, 2:02 PM, Peter Eisentraut wrote: >> >> >But having the same param

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

On Thu, Sep 25, 2014 at 4:49 PM, Stephen Frost wrote: > * Gregory Smith (gregsmithpg...@gmail.com) wrote: >> On 9/25/14, 2:02 PM, Peter Eisentraut wrote: >> >But having the same parameter setting mean different things in >> >different versions is the path to complete madness. >> >> Could we go so

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

* Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Sep 25, 2014 at 4:49 PM, Stephen Frost wrote: > > * Gregory Smith (gregsmithpg...@gmail.com) wrote: > >> On 9/25/14, 2:02 PM, Peter Eisentraut wrote: > >> >But having the same parameter setting mean different things in > >> >different versions

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

* Gregory Smith (gregsmithpg...@gmail.com) wrote: > On 9/25/14, 2:02 PM, Peter Eisentraut wrote: > >But having the same parameter setting mean different things in > >different versions is the path to complete madness. > > Could we go so far as to remove support for unitless time settings > eventua

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

On 9/25/14, 2:02 PM, Peter Eisentraut wrote: But having the same parameter setting mean different things in different versions is the path to complete madness. Could we go so far as to remove support for unitless time settings eventually? The fact that people are setting raw numbers in the

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

On 9/25/14 11:03 AM, Robert Haas wrote: > I couldn't agree more. There's something to be said for just leaving > this alone. I agree. > potentitally draw complaints. But I also agree with his last one - of > those three possible complaints, I certainly prefer "I had to fix my > configuration fi

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

* Robert Haas (robertmh...@gmail.com) wrote: > On Thu, Sep 25, 2014 at 12:46 AM, Tom Lane wrote: > > TBH I've also been wondering whether any of these proposed cures are > > better than the disease. > > I couldn't agree more. There's something to be said for just leaving > this alone. I've been

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

On Thu, Sep 25, 2014 at 12:46 AM, Tom Lane wrote: > TBH I've also been wondering whether any of these proposed cures are > better than the disease. I couldn't agree more. There's something to be said for just leaving this alone. > The changes that can be argued to make the > behavior more sane

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

On Thursday, September 25, 2014, Gregory Smith wrote: > On 9/25/14, 1:41 AM, David Johnston wrote: > >> If the error message is written correctly most people upon seeing the >> error will simply fix their configuration and move on - regardless of >> whether they were proactive in doing so having

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

On 9/25/14, 1:41 AM, David Johnston wrote: If the error message is written correctly most people upon seeing the error will simply fix their configuration and move on - regardless of whether they were proactive in doing so having read the release notes. The important part to realize here is th

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

On Thu, Sep 25, 2014 at 1:04 AM, Tom Lane wrote: > David Johnston writes: > > On Thu, Sep 25, 2014 at 12:46 AM, Tom Lane wrote: > >> TBH I've also been wondering whether any of these proposed cures are > >> better than the disease. The changes that can be argued to make the > >> behavior more

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

David Johnston writes: > On Thu, Sep 25, 2014 at 12:46 AM, Tom Lane wrote: >> TBH I've also been wondering whether any of these proposed cures are >> better than the disease. The changes that can be argued to make the >> behavior more sane are also ones that introduce backwards compatibility >>

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

On Thu, Sep 25, 2014 at 12:46 AM, Tom Lane wrote: > Gregory Smith writes: > > I don't see any agreement on the real root of a problem here yet. That > > makes gauging whether any smaller change leads that way or not fuzzy. I > > personally would be fine doing nothing right now, instead waiting

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

On Thu, Sep 25, 2014 at 12:11 AM, Gregory Smith wrote: > On 9/24/14, 6:45 PM, Peter Eisentraut wrote: > >> But then this proposal is just one of several others that break backward >> compatibility, and does so in a more or less silent way. Then we might >> as well pick another approach that gets

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

Gregory Smith writes: > I don't see any agreement on the real root of a problem here yet. That > makes gauging whether any smaller change leads that way or not fuzzy. I > personally would be fine doing nothing right now, instead waiting until > that's charted out--especially if the alternative

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

On 9/24/14, 6:45 PM, Peter Eisentraut wrote: But then this proposal is just one of several others that break backward compatibility, and does so in a more or less silent way. Then we might as well pick another approach that gets closer to the root of the problem. I was responding to some desir

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

On 9/23/14 11:55 PM, Gregory Smith wrote: > Right now there are people out there who have configurations that look > like this: > > log_rotation_age=60 > > In order to get hourly rotation. These users will suffer some trauma > should they upgrade to a version where this parameter now means a new

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

On 9/23/14, 10:52 PM, David Johnston wrote: ​Given the following why not just pick "ms" for log_rotation_age now? Right now there are people out there who have configurations that look like this: log_rotation_age=60 In order to get hourly rotation. These users will suffer some trauma shou

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

On Tue, Sep 23, 2014 at 10:11 PM, Gregory Smith wrote: > On 9/23/14, 1:21 AM, David Johnston wrote: > >> This patch should fix the round-to-zero issue. If someone wants to get >> rid of zero as a special case let them supply a separate patch for that >> "improvement". >> > > I am going to wander

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

On 9/23/14, 1:21 AM, David Johnston wrote: This patch should fix the round-to-zero issue. If someone wants to get rid of zero as a special case let them supply a separate patch for that "improvement". I am going to wander into this fresh after just reading everything once (but with more than

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

Peter Eisentraut writes: > On 9/23/14 10:29 AM, Tom Lane wrote: >> Votes or no votes, that's a horrible idea; it breaks the design goal >> that users shouldn't need to remember the precise unit size when making >> postgresql.conf entries. > I think this is not historically correct. > The origina

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

On 9/23/14 1:13 AM, Stephen Frost wrote: > To clarify- we'll simply swap from (essentially) floor() to ceil() for > handling all GUC_with_unit to internal_unit conversions, document that, > and note it in the release notes as a possible behavior change and move > on. That'll probably work, as long

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

On 9/23/14 10:29 AM, Tom Lane wrote: > Votes or no votes, that's a horrible idea; it breaks the design goal > that users shouldn't need to remember the precise unit size when making > postgresql.conf entries. I think this is not historically correct. The original motivation was that you had to re

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

On Tue, Sep 23, 2014 at 3:05 PM, Greg Stark wrote: > Fwiw I agree with TL2. The simplest, least surprising behaviour to explain > to users is to say we round to nearest and if that means we rounded to zero > (or another special value) we throw an error. We could list the minimum > value in pg_set

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

Fwiw I agree with TL2. The simplest, least surprising behaviour to explain to users is to say we round to nearest and if that means we rounded to zero (or another special value) we throw an error. We could list the minimum value in pg_settings and maybe in documentation. -- greg

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

On 09/23/2014 06:23 PM, Andrew Dunstan wrote: On 09/23/2014 10:29 AM, Tom Lane wrote: Robert Haas writes: Three people have voted for making it an *error* to supply a value that needs to be rounded, instead of changing the rounding behavior. Votes or no votes, that's a horrible idea; it brea

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

On Tue, Sep 23, 2014 at 1:30 AM, Tom Lane wrote: > David Johnston writes: > > My original concern was things that are rounded to zero now will not be > in > > 9.5 if the non-error solution is chosen. The risk profile is extremely > > small but it is not theoretically zero. > > This is exactly t

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

On 09/23/2014 10:29 AM, Tom Lane wrote: Robert Haas writes: Three people have voted for making it an *error* to supply a value that needs to be rounded, instead of changing the rounding behavior. Votes or no votes, that's a horrible idea; it breaks the design goal that users shouldn't need to

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

On Tue, Sep 23, 2014 at 10:29 AM, Tom Lane wrote: > Robert Haas writes: >> Three people have voted for making it an *error* to supply a value >> that needs to be rounded, instead of changing the rounding behavior. > > Votes or no votes, that's a horrible idea; it breaks the design goal > that use

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

Robert Haas writes: > Three people have voted for making it an *error* to supply a value > that needs to be rounded, instead of changing the rounding behavior. Votes or no votes, that's a horrible idea; it breaks the design goal that users shouldn't need to remember the precise unit size when mak

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

On Tue, Sep 23, 2014 at 1:23 AM, Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Stephen Frost writes: >> > To clarify- we'll simply swap from (essentially) floor() to ceil() for >> > handling all GUC_with_unit to internal_unit conversions, document that, >> > and note it in the

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

Hi Stephen, As you said, I'm not good at English, so I'm glad you handle this thread. I'll wait for the good changing. Thank you very very much! regards, -- Tomonari Katsumata 2014-09-23 14:23 GMT+09:00 Stephen Frost : > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Stephen Frost

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

David Johnston writes: > My original concern was things that are rounded to zero now will not be in > 9.5 if the non-error solution is chosen. The risk profile is extremely > small but it is not theoretically zero. This is exactly the position I was characterizing as an excessively narrow-minded

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

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > To clarify- we'll simply swap from (essentially) floor() to ceil() for > > handling all GUC_with_unit to internal_unit conversions, document that, > > and note it in the release notes as a possible behavior change and move > > on.

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

On Tuesday, September 23, 2014, Tom Lane wrote: > David G Johnston > writes: > > Can you either change your mind back to this opinion you held last month > or > > commit something you find acceptable - its not like anyone would revert > > something you commit... :) > > Hey, am I not allowed to ch

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

Stephen Frost writes: > To clarify- we'll simply swap from (essentially) floor() to ceil() for > handling all GUC_with_unit to internal_unit conversions, document that, > and note it in the release notes as a possible behavior change and move > on. Worksforme. regards, to

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

* Tom Lane (t...@sss.pgh.pa.us) wrote: > > Here's another proposal- how about we support a 'minimum-if-not-zero' > > option for GUCs more generally, and then throw an error if the user sets > > the value to a value below that minimum unless they explicitly use zero > > (to indicate whatever the spe

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

David G Johnston writes: > Can you either change your mind back to this opinion you held last month or > commit something you find acceptable - its not like anyone would revert > something you commit... :) Hey, am I not allowed to change my mind :-) ? Seriously though, the main point I was makin

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

Tom Lane-2 wrote > The case where this argument falls down is for "special" values, such as > where zero means something quite different from the smallest nonzero > value. Peter suggested upthread that we should redefine any GUC values > for which that is true, but (a) I think that loses on backwa

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

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> 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 >> consisten

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

Hey Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost 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 z

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

Stephen Frost 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

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

Tomonari, * 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. > > I attached new patch. > T

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

Hi, I'm sorry for slow reaction. I don't care whether rounding up or down it, although this title has 'rounding up'. (I just only come up with it. I'm sorry for my imprudence) I'm thinking about a method which users get quick awareness it. Now, it's okay not to change current behavior except non

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

Tom Lane-2 wrote > Robert Haas < > robertmhaas@ > > writes: >> I liked David Johnston's even stronger suggestion upthread: make it an >> error to specify a value requires rounding of any kind. In other >> words, if the minimum granularity is 1 minute, you can specify that as >> 60 seconds instea

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

Robert Haas writes: > I liked David Johnston's even stronger suggestion upthread: make it an > error to specify a value requires rounding of any kind. In other > words, if the minimum granularity is 1 minute, you can specify that as > 60 seconds instead, but if you write 59 seconds, we error out.

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

On 8/26/14 4:22 PM, Andres Freund wrote: > Is the whole topic actually practically relevant? It's clearly not all that important, or otherwise we'd have heard about before now. I suppose someone could do something like wal_receiver_status_interval = 10ms and end up silently turning the whole th

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

On 8/23/14 6:39 PM, Greg Stark wrote: > Or make it an error to specify a value that rounds to 0 but isn't 0. That's what I would prefer. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

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

On 2014-08-26 16:16:32 -0400, Robert Haas wrote: > On Sat, Aug 23, 2014 at 6:39 PM, Greg Stark wrote: > > On Sat, Aug 23, 2014 at 9:38 PM, Tom Lane wrote: > >> > >> Ah. Okay, but then what's wrong with the original proposal of "use ceil() > >> instead of floor()"? Basically I think the idea of

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

On Sat, Aug 23, 2014 at 6:39 PM, Greg Stark wrote: > On Sat, Aug 23, 2014 at 9:38 PM, Tom Lane wrote: >> >> Ah. Okay, but then what's wrong with the original proposal of "use ceil() >> instead of floor()"? Basically I think the idea of treating fractions >> less than one differently from fracti

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

Tom Lane-2 wrote > David G Johnston < > david.g.johnston@ > > writes: >> Tom Lane-2 wrote >>> Indeed. I have not understood why you are insisting on "round up" >>> semantics. Wouldn't it make more sense for the behavior to be "round to >>> nearest"? That would get rid of any worries about trea

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

On Sat, Aug 23, 2014 at 9:38 PM, Tom Lane wrote: > > Ah. Okay, but then what's wrong with the original proposal of "use ceil() > instead of floor()"? Basically I think the idea of treating fractions > less than one differently from fractions greater than one is bogus; nobody > will ever find tha

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

David G Johnston writes: > Tom Lane-2 wrote >> Indeed. I have not understood why you are insisting on "round up" >> semantics. Wouldn't it make more sense for the behavior to be "round to >> nearest"? That would get rid of any worries about treating zero >> specially. > Wasn't the goal that al

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

Tom Lane-2 wrote > Tomonari Katsumata < > t.katsumata1122@ > > writes: >> This patch rounds up the value when only it's less than required unit. >> .. >> Although my original complaint is fixed, I'm worried about this change >> will >> make users confusing. > > Indeed. I have not understood why

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

Tomonari Katsumata writes: > This patch rounds up the value when only it's less than required unit. > .. > Although my original complaint is fixed, I'm worried about this change will > make users confusing. Indeed. I have not understood why you are insisting on "round up" semantics. Wouldn't it

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

Thank you for the comments. It was a bug in my patch as another developer says. I've not considered about the value 'zero', sorry. I attached new patch. This patch rounds up the value when only it's less than required unit. Like below. (unit: min) 0->0 0s->0 10s->1 70s->1 Although my original co

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

Peter Eisentraut-2 wrote > On 8/21/14 11:16 AM, Tom Lane wrote: >> Heikki Linnakangas < > hlinnakangas@ > > writes: >>> The patch also rounds a zero up to one. A naked zero with no unit is not >>> affected, but e.g if you have "log_rotation_age=0s", it will not disable >>> the feature as you mi

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

On 8/21/14 11:16 AM, Tom Lane wrote: > Heikki Linnakangas writes: >> The patch also rounds a zero up to one. A naked zero with no unit is not >> affected, but e.g if you have "log_rotation_age=0s", it will not disable >> the feature as you might expect, but set it to 1 minute. Should we do >> s

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

Heikki Linnakangas writes: > The patch also rounds a zero up to one. A naked zero with no unit is not > affected, but e.g if you have "log_rotation_age=0s", it will not disable > the feature as you might expect, but set it to 1 minute. Should we do > something about that? That sounds like a de

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

On 07/10/2014 09:52 AM, Tomonari Katsumata wrote: Hi, Several couple weeks ago, I posted a mail to pgsql-doc. http://www.postgresql.org/message-id/53992ff8.2060...@po.ntts.co.jp In this thread, I concluded that it's better to round up the value which is less than its unit. Current behavior (rou

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

Hi Robert, Thank you for checking this! I've added it to commitfest. https://commitfest.postgresql.org/action/patch_view?id=1507 regards, Tomonari Katsumata 2014-07-12 6:07 GMT+09:00 Robert Haas : > On Thu, Jul 10, 2014 at 2:52 AM, Tomonari Katsumata > wrote: > > Several couple

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

On Thu, Jul 10, 2014 at 2:52 AM, Tomonari Katsumata wrote: > Several couple weeks ago, I posted a mail to pgsql-doc. > http://www.postgresql.org/message-id/53992ff8.2060...@po.ntts.co.jp > > In this thread, I concluded that it's better to > round up the value which is less than its unit. > Current

[HACKERS] proposal: rounding up time value less than its unit.

Hi, Several couple weeks ago, I posted a mail to pgsql-doc. http://www.postgresql.org/message-id/53992ff8.2060...@po.ntts.co.jp In this thread, I concluded that it's better to round up the value which is less than its unit. Current behavior (rounding down) has undesirable setting risk, because so