Re: truncating timestamps on arbitrary intervals
От | Peter Eisentraut |
---|---|
Тема | Re: truncating timestamps on arbitrary intervals |
Дата | |
Msg-id | 13c3c072-39de-23d2-b743-98803bc8a422@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: truncating timestamps on arbitrary intervals (John Naylor <john.naylor@enterprisedb.com>) |
Список | pgsql-hackers |
On 10.04.21 14:53, John Naylor wrote: > > On Sat, Apr 10, 2021 at 7:43 AM Peter Eisentraut > <peter.eisentraut@enterprisedb.com > <mailto:peter.eisentraut@enterprisedb.com>> wrote: > > > > On 30.03.21 18:06, John Naylor wrote: > > > Currently, when the origin is after the input, the result is the > > > timestamp at the end of the bin, rather than the beginning as expected. > > > The attached puts the result consistently at the beginning of the bin. > > > > In the patch > > > > + if (origin > timestamp && stride_usecs > 1) > > + tm_delta -= stride_usecs; > > > > is the condition stride_usecs > 1 really necessary? My assessment is > > that it's not, in which case it would be better to omit it. > > Without the condition, the case of 1 microsecond will fail to be a > no-op. This case has no practical use, but it still must work correctly, > just as date_trunc('microsecond', input) does. Ah yes, the tests cover that. Committed.
В списке pgsql-hackers по дате отправления: