Re: Bad canonicalization for dateranges with 'infinity' bounds

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

In response to

Responses

Browse pgsql-hackers by date

  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