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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: proposal: rounding up time value less than its unit.
Дата
Msg-id 7639.1411752161@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: proposal: rounding up time value less than its unit.  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: proposal: rounding up time value less than its unit.  (Stephen Frost <sfrost@snowman.net>)
Re: proposal: rounding up time value less than its unit.  (David Johnston <david.g.johnston@gmail.com>)
Re: proposal: rounding up time value less than its unit.  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> 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
> value of 0 is more surprising than rounding 30 seconds up to a minute,
> but the latter is still surprising.  We're generally not averse to
> tighter validation, so why here?

So in other words, if I set "shared_buffers = 100KB", you are proposing
that that be rejected because it's not an exact multiple of 8KB?  This
seems like it's throwing away one of the fundamental reasons why we
invented GUC units in the first place.

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 completely not impressed by arguments based on such cases.
The right fix for such a case is to choose a different unit for the GUC.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Replication identifiers, take 3
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: proposal: rounding up time value less than its unit.