Re: Range Types - typo + NULL string constructor - Mailing list pgsql-hackers

From Thom Brown
Subject Re: Range Types - typo + NULL string constructor
Date
Msg-id CAA-aLv62N_nAOovK85dDPMwkQdpTNQw5RYNURbmXiBHT_t64Kw@mail.gmail.com
Whole thread Raw
In response to Re: Range Types - typo + NULL string constructor  (Thom Brown <thom@linux.com>)
Responses Re: Range Types - typo + NULL string constructor  (Florian Pflug <fgp@phlo.org>)
List pgsql-hackers
On 10 October 2011 18:53, Thom Brown <thom@linux.com> wrote:
> On 10 October 2011 18:45, Jeff Davis <pgsql@j-davis.com> wrote:
>> On Mon, 2011-10-10 at 18:39 +0100, Thom Brown wrote:
>>>  So the default boundaries should be '[]' as opposed to '[)' as it is
>>> now.
>>
>> Would that vary between range types? In other words, do I bring back
>> default_flags?
>>
>> If not, I think a lot of people will object. The most common use-case
>> for range types are for continuous ranges like timestamps. And (as I
>> pointed out in reply to Florian) there are good reasons to use the '[)'
>> convention for those cases.
>
> I'm proposing it for discrete ranges.  For continuous ranges, I guess
> it makes sense to have "up to, but not including".  The same boundary
> inclusivity/exclusivity thing seems unintuitive for discrete ranges.
> This has the downside of inconsistency, but I don't think that's
> really a solid argument against it since their use will be different
> anyway.

Okay, a real example of why discrete should be '[]' and continuous
should be '[)'.

If you book a meeting from 09:00 to 11:00 (tsrange), at 11:00
precisely it either becomes free or is available to someone else, so
it can be booked 11:00 to 12:00 without conflict.

If you have raffle tickets numbered 1 to 100 (int4range), and you ask
for tickets 9 to 11, no-one else can use 11 as it aligns with the last
one you bought.

So for me, it's intuitive for them to behave differently.  So yes,
default behaviour would vary between types, but I didn't previously
read anything on default_flags, so I don't know where that comes into
it.  Shouldn't it be the case that if a type has a canonical function,
it's entirely inclusive, otherwise it's upper boundary is exclusive?

--
Thom Brown
Twitter: @darkixion
IRC (freenode): dark_ixion
Registered Linux user: #516935

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Thom Brown
Date:
Subject: Re: Range Types - typo + NULL string constructor
Next
From: Robert Haas
Date:
Subject: Re: ALTER EXTENSION .. ADD/DROP weirdness