I wrote: > On Thu, Jul 22, 2021 at 4:49 PM Bauyrzhan Sakhariyev < baurzhansahar...@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
0001-Disallow-negative-strides-in-date_bin.patch
Description: Binary data
