Re: truncating timestamps on arbitrary intervals
| От | Salek Talangi |
|---|---|
| Тема | Re: truncating timestamps on arbitrary intervals |
| Дата | |
| Msg-id | CACX8wBfHPKn7-2wo-32kTo_KQ5tsR_xvrFWDEUEzZZQw4CmcnQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: truncating timestamps on arbitrary intervals (John Naylor <john.naylor@enterprisedb.com>) |
| Ответы |
Re: truncating timestamps on arbitrary intervals
|
| Список | 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 onesNote 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 по дате отправления: