From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Bad canonicalization for dateranges with 'infinity' bounds |
Date: | 2019-07-13 12:44:39 |
Message-ID: | CA+hUKGJ0gUs-BMRwCgQF-dtURq_7aT1Ecum22u2jH2CcdEQAYw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, May 3, 2019 at 12:49 AM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
> > I propose the attached patch which fixes the problem.
Hi Laurenz,
I agree that the patch makes the code match the documentation. The
documented behaviour seems to make more sense than the code, since
unpatched master gives this nonsense result when it flips the
inclusive flag but doesn't adjust the value (because it can't):
postgres=# select '(-infinity,infinity]'::daterange @> 'infinity'::date;
?column?
----------
f
(1 row)
- if (!upper.infinite && upper.inclusive)
+ if (!(upper.infinite || DATE_NOT_FINITE(upper.val)) && upper.inclusive)
Even though !(X || Y) is equivalent to !X && !Y, by my reading of
range_in(), lower.value can be uninitialised when lower.infinite is
true, and it's also a bit hard to read IMHO, so I'd probably write
that as !upper.infinite && !DATE_NOT_FINITE(upper.val) &&
upper.inclusive. I don't think it can affect the result but it might
upset Valgrind or similar.
--
Thomas Munro
https://enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2019-07-13 13:38:06 | Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS) |
Previous Message | Peter Eisentraut | 2019-07-13 12:44:13 | Re: initdb recommendations |