On 18.01.21 21:54, John Naylor wrote:
On Mon, Nov 23, 2020 at 1:44 PM John Naylor
<john.nay...@enterprisedb.com <mailto:john.nay...@enterprisedb.com>> wrote:
>
> On Thu, Nov 12, 2020 at 9:56 AM Peter Eisentraut
<peter.eisentr...@enterprisedb.com
<mailto:peter.eisentr...@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.
