Re: truncating timestamps on arbitrary intervals
Peter Eisentraut <peter.eisentraut@enterprisedb.com>
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: John Naylor <john.naylor@enterprisedb.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-03-24T15:38:10Z
Lists: 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.
Commits
-
Disallow negative strides in date_bin()
- fc0d9b8c224f 14.0 landed
- 3ba70d4e1523 15.0 landed
-
Improve behavior of date_bin with origin in the future
- 496e58bb0e5e 14.0 landed
-
doc: Additional documentation for date_bin
- 49fb4e6b2490 14.0 landed
-
Add date_bin function
- 49ab61f0bdc9 14.0 landed