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

Поиск
Список
Период
Сортировка
От David Johnston
Тема Re: proposal: rounding up time value less than its unit.
Дата
Msg-id CAKFQuwYJF98uP3_32Nebp9P7t4bhYkFE4uvr90KVMMHWCEmQBQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: proposal: rounding up time value less than its unit.  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: proposal: rounding up time value less than its unit.  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, Sep 25, 2014 at 12:46 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Gregory Smith <gregsmithpgsql@gmail.com> 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 is applying any of the
> rounding or error throwing ideas suggested so far.  I'd say that I hate
> to be that guy who tells everyone else they're wrong, but we all know I
> enjoy it.

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
issues of one magnitude or another.  And I do not have a lot of sympathy
for "let's not change anything except to throw an error in a case that
seems ambiguous".  That's mostly being pedantic, not helpful, especially
seeing that the number of field complaints about it is indistinguishable
from zero.


​Then what does it matter that we'd choose to error-out?​
 
I am personally not as scared of backwards-compatibility problems as some
other commenters: I do not think that there's ever been a commitment that
postgresql.conf contents will carry forward blindly across major releases.
So I'd be willing to break strict compatibility in the name of making the
behavior less surprising.  But the solutions that have been proposed that
hold to strict backwards compatibility requirements are not improvements
IMHO.

​Or, put differently, the pre-existing behavior is fine so don't fix what isn't broken.  

This patch simply fixes an oversight in the original implementation - that someone might try to specify an invalid value (i.e., between 0 and 1).  if 0 and -1 are flags, then the minimum allowable value is 1.  The logic should have been: range [1, something]; 0 (optionally); -1 (optionally).  Values abs(x) between 0 and 1 (exclusive) should be disallowed and, like an attempt to specify 0.5 (without units), should throw an error.

David J.

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

Предыдущее
От: Abhijit Menon-Sen
Дата:
Сообщение: Re: a fast bloat measurement tool (was Re: Measuring relation free space)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: proposal: rounding up time value less than its unit.