Re: truncating timestamps on arbitrary intervals

David Steele <david@pgmasters.net>

From: David Steele <david@pgmasters.net>
To: John Naylor <john.naylor@enterprisedb.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-03-19T14:54:53Z
Lists: pgsql-hackers
On 1/18/21 3:54 PM, 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.

Peter, thoughts on the new patch?

Regards,
-- 
-David
david@pgmasters.net



Commits

  1. Disallow negative strides in date_bin()

  2. Improve behavior of date_bin with origin in the future

  3. doc: Additional documentation for date_bin

  4. Add date_bin function