| 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: | Whole Thread | Raw Message | 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.
| 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 |