Re: empty range

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: emre(at)hasegeli(dot)com
Cc: david(dot)turon(at)linuxbox(dot)cz, pgsql-hackers(at)postgresql(dot)org
Subject: Re: empty range
Date: 2020-01-16 15:21:02
Message-ID: 19461.1579188062@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Emre Hasegeli <emre(at)hasegeli(dot)com> writes:
>> It's only suggestion, i don't now if somebody wants store empty range without bounds.

> I thought about the same while developing the BRIN inclusion operator
> class. I am not sure how useful empty ranges are in practice, but
> keeping their bound would only bring more flexibility, and eliminate
> special cases on most of the range operators. For reference, we allow
> empty boxes, and none of the geometric operators has to handle them
> specially.

I think it'd just move the special cases somewhere else. Consider

regression=# select int4range(4,4) = int4range(5,5);
?column?
----------
t
(1 row)

How do you preserve that behavior ... or if you don't, how much
damage does that do to the semantics of ranges? Right now there's
a pretty solid set-theoretic basis for understanding what a range is,
ie two ranges are the same if they include the same sets of elements.
It seems like that goes out the window if we don't consider that
all empty ranges are the same.

BTW, I think the main reason for all the bound-normalization pushups
is to try to have a rule that ranges that are set-theoretically equal
will look the same. That also goes out the window if we make
empty ranges look like this.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Antonin Houska 2020-01-16 15:25:50 Re: [HACKERS] WIP: Aggregation push-down
Previous Message Justin Pryzby 2020-01-16 15:19:31 Re: progress report for ANALYZE