Re: truncating timestamps on arbitrary intervals
От | Peter Eisentraut |
---|---|
Тема | Re: truncating timestamps on arbitrary intervals |
Дата | |
Msg-id | 97226e7e-19a8-d19b-89c2-9677c5200d9d@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: truncating timestamps on arbitrary intervals (John Naylor <john.naylor@enterprisedb.com>) |
Ответы |
Re: truncating timestamps on arbitrary intervals
Re: truncating timestamps on arbitrary intervals |
Список | pgsql-hackers |
On 18.01.21 21:54, John Naylor wrote: > On Mon, Nov 23, 2020 at 1:44 PM John Naylor > <john.naylor@enterprisedb.com <mailto:john.naylor@enterprisedb.com>> wrote: > > > > On Thu, Nov 12, 2020 at 9:56 AM Peter Eisentraut > <peter.eisentraut@enterprisedb.com > <mailto:peter.eisentraut@enterprisedb.com>> wrote: > > > - After reading the discussion a few times, I'm not so sure anymore > > > whether making this a cousin of date_trunc is the right way to go. As > > > you mentioned, there are some behaviors specific to date_trunc that > > > don't really make sense in date_trunc_interval, and maybe we'll have > > > more of those. > > For v10, I simplified the behavior by decoupling the behavior from > date_trunc() and putting in some restrictions as discussed earlier. It's > much simpler now. It could be argued that it goes too far in that > direction, but it's easy to reason about and we can put back some > features as we see fit. Committed. I noticed that some of the documentation disappeared between v9 and v10. So I put that back and updated it appropriately. I also added a few more test cases to cover some things that have been discussed during the course of this thread. As a potential follow-up, should we perhaps add named arguments? That might make the invocations easier to read, depending on taste.
В списке pgsql-hackers по дате отправления: