Re: truncating timestamps on arbitrary intervals
От | John Naylor |
---|---|
Тема | Re: truncating timestamps on arbitrary intervals |
Дата | |
Msg-id | CAFBsxsEwQfQg0mby5OZZuCkCSfHno4nF6SXvKCS5YP1Yb1kjXg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: truncating timestamps on arbitrary intervals (John Naylor <john.naylor@enterprisedb.com>) |
Ответы |
Re: truncating timestamps on arbitrary intervals
Re: truncating timestamps on arbitrary intervals |
Список | pgsql-hackers |
I wrote:
> On Thu, Jul 22, 2021 at 4:49 PM Bauyrzhan Sakhariyev <baurzhansahariev@gmail.com> wrote:
> >
> > > No, the boundary is intentionally the earlier one:
> >
> > I found that commit in GitHub, thanks for pointing it out.
> > When I test locally origin_in_the_future case I get different results for positive and negative intervals (see queries #1 and #2 from above, they have same timestamp, origin and interval magnitude, difference is only in interval sign) - can it be that the version I downloaded from https://www.enterprisedb.com/postgresql-early-experience doesn't include commit with that improvement?
>
> Sorry, I wasn't clear. The intention is that the boundary is on the lower side, but query #1 doesn't follow that, so that's a bug in my view. I found while developing the feature that the sign of the stride didn't seem to matter, but evidently I didn't try with the origin in the future.
>
> > > I wonder if we should just disallow negative intervals here.
> >
> > I cannot imagine somebody using negative as a constant argument but users can pass another column as a first argument date or some function(ts) - not likely but possible. A line in docs about the leftmost point of interval as start of the bin could be helpful.
>
> In recent years there have been at least two attempts to add an absolute value function for intervals, and both stalled over semantics, so I'd rather just side-step the issue, especially as we're in beta.
Concretely, I propose to push the attached on master and v14. Since we're in beta 2 and this thread might not get much attention, I've CC'd the RMT.
--
John Naylor
EDB: http://www.enterprisedb.com
> On Thu, Jul 22, 2021 at 4:49 PM Bauyrzhan Sakhariyev <baurzhansahariev@gmail.com> wrote:
> >
> > > No, the boundary is intentionally the earlier one:
> >
> > I found that commit in GitHub, thanks for pointing it out.
> > When I test locally origin_in_the_future case I get different results for positive and negative intervals (see queries #1 and #2 from above, they have same timestamp, origin and interval magnitude, difference is only in interval sign) - can it be that the version I downloaded from https://www.enterprisedb.com/postgresql-early-experience doesn't include commit with that improvement?
>
> Sorry, I wasn't clear. The intention is that the boundary is on the lower side, but query #1 doesn't follow that, so that's a bug in my view. I found while developing the feature that the sign of the stride didn't seem to matter, but evidently I didn't try with the origin in the future.
>
> > > I wonder if we should just disallow negative intervals here.
> >
> > I cannot imagine somebody using negative as a constant argument but users can pass another column as a first argument date or some function(ts) - not likely but possible. A line in docs about the leftmost point of interval as start of the bin could be helpful.
>
> In recent years there have been at least two attempts to add an absolute value function for intervals, and both stalled over semantics, so I'd rather just side-step the issue, especially as we're in beta.
Concretely, I propose to push the attached on master and v14. Since we're in beta 2 and this thread might not get much attention, I've CC'd the RMT.
--
John Naylor
EDB: http://www.enterprisedb.com
Вложения
В списке pgsql-hackers по дате отправления: