Re: truncating timestamps on arbitrary intervals - Mailing list pgsql-hackers

From Salek Talangi
Subject Re: truncating timestamps on arbitrary intervals
Date
Msg-id CACX8wBfHPKn7-2wo-32kTo_KQ5tsR_xvrFWDEUEzZZQw4CmcnQ@mail.gmail.com
Whole thread Raw
In response to Re: truncating timestamps on arbitrary intervals  (John Naylor <john.naylor@enterprisedb.com>)
Responses Re: truncating timestamps on arbitrary intervals  (John Naylor <john.naylor@enterprisedb.com>)
List pgsql-hackers
Hi all,

it might be a bit late now, but do you know that TimescaleDB already has a similar feature, named time_bucket?
Perhaps that can help with some design decisions.
I saw your feature on Depesz' "Waiting for PostgreSQL 14" and remembered reading about it just two days ago.

Best regards
Salek Talangi

Am Do., 1. Apr. 2021 um 13:31 Uhr schrieb John Naylor <john.naylor@enterprisedb.com>:
On Sat, Mar 27, 2021 at 1:06 PM Justin Pryzby <pryzby@telsasoft.com> wrote:
>
> The current docs seem to be missing a "synopsis", like
>
> +<synopsis>
> +date_trunc(<replaceable>stride</replaceable>, <replaceable>timestamp</replaceable>, <replaceable>origin</replaceable>)
> +</synopsis>

The attached 
- adds a synopsis 
- adds a bit more description to the parameters similar to those in date_trunc
- documents that negative intervals are treated the same as positive ones

Note on the last point: This just falls out of the math, so was not deliberate, but it seems fine to me. We could ban negative intervals, but that would possibly just inconvenience some people unnecessarily. We could also treat negative strides differently somehow, but I don't immediately see a useful and/or intuitive change in behavior to come of that.

--
John Naylor
EDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Zhihong Yu
Date:
Subject: Re: Crash in BRIN minmax-multi indexes
Next
From: Amit Langote
Date:
Subject: Re: ModifyTable overheads in generic plans