Re: mark the timestamptz variant of date_bin() as stable

Поиск
Список
Период
Сортировка
От John Naylor
Тема Re: mark the timestamptz variant of date_bin() as stable
Дата
Msg-id CAFBsxsHVSSD7vLQnTmNwToO7NSLSesDutq0snn=fqUut-OvFDQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: mark the timestamptz variant of date_bin() as stable  (Aleksander Alekseev <aleksander@timescale.com>)
Ответы Re: mark the timestamptz variant of date_bin() as stable  (John Naylor <john.naylor@enterprisedb.com>)
Список pgsql-hackers

On Thu, Sep 23, 2021 at 4:13 AM Aleksander Alekseev <aleksander@timescale.com> wrote:
>
> Hi John,
>
> > Any thoughts on the doc patch?
>
> It so happened that I implemented a similar feature in TimescaleDB [1].
>
> I discovered that it's difficult from both developer's and user's
> perspectives to think about the behavior of the function in the
> context of given TZ and its complicated rules, as you are trying to do
> in the doc patch. So what we did instead is saying: for timestamptz
> the function works as if it was timestamp. E.g. time_bucket_ng("3
> month", "2021 Oct 03 12:34:56 TZ") = "2021 Jan 01 00:00:00 TZ" no
> matter what TZ it is and what rules (DST, corrections, etc) it has. It
> seems to be not only logical and easy to understand, but also easy to
> implement [2].
>
> Do you think it would be possible to adopt a similar approach in
> respect of documenting for date_bin()? To be honest, I didn't try to
> figure out what is the actual implementation of date_bin() for TZ
> case.

I think you have a point that it could be stated more simply and generally. I'll try to move in that direction.

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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Hook for extensible parsing.
Следующее
От: Robert Haas
Дата:
Сообщение: Re: extensible options syntax for replication parser?