Re: truncating timestamps on arbitrary intervals

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: truncating timestamps on arbitrary intervals
Date: 2021-03-24 15:38:10
Message-ID: 97226e7e-19a8-d19b-89c2-9677c5200d9d@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2021-03-24 15:41:31 Re: [HACKERS] Custom compression methods
Previous Message Robert Haas 2021-03-24 15:29:09 Re: default result formats setting