On 01/12/2016 12:12, Francisco Olarte wrote:
> On Thu, Dec 1, 2016 at 12:56 PM, Chris Withers <chris@simplistix.co.uk> wrote:
>> So, first observation: if I make room nullable, the exclude constraint does
>> not apply for rows that have a room of null. I guess that's to be expected,
>> right?
>
> I would expect it, given:
>
> n=> select null=null, null<>null, not (null=null);
> ?column? | ?column? | ?column?
> ----------+----------+----------
> | |
> (1 row)
>
> Those are nulls,
Yes, it's a shame psql has the same repr for null and empty-string ;-)
> n=> select (null=null) is null, (null<>null) is null, (not (null=null)) is null;
> ?column? | ?column? | ?column?
> ----------+----------+----------
> t | t | t
> (1 row)
>
> I.e., the same happens with a nullable unique column, you can have one
> of each not null values and as many nulls as you want.
>
> SQL null is a strange beast.
Sure, I think that was the answer I was expecting but not hoping for...
However, my "next question" was the one I was really hoping for help with:
Working with the exclude constraint example from
https://www.postgresql.org/docs/current/static/rangetypes.html:
CREATE EXTENSION btree_gist;
CREATE TABLE room_reservation (
room text,
during tsrange,
EXCLUDE USING GIST (room WITH =, during WITH &&)
);
Next question: if lots of rows have open-ended periods
(eg: [, 2010-01-01 15:00) or [2010-01-01 14:00,)), how does that affect
the performance of the btree gist index backing the exclude constraint?
Tom Lane made a comment on here but never followed up with a definitive
answer. Can anyone else help?
cheers,
Chris
