From: | David Steele <david(at)pgmasters(dot)net> |
---|---|
To: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: truncating timestamps on arbitrary intervals |
Date: | 2021-03-19 14:54:53 |
Message-ID: | 83047643-c352-4d3b-b886-cd0f0d071289@pgmasters.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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(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.
Peter, thoughts on the new patch?
Regards,
--
-David
david(at)pgmasters(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Emre Hasegeli | 2021-03-19 14:55:24 | Re: default result formats setting |
Previous Message | David Steele | 2021-03-19 14:53:53 | Re: support for MERGE |