From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Thom Brown <thom(at)linux(dot)com> |
Cc: | Florian Pflug <fgp(at)phlo(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Erik Rijkers <er(at)xs4all(dot)nl>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Range Types - typo + NULL string constructor |
Date: | 2011-10-10 16:44:51 |
Message-ID: | 1318265091.1724.129.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 2011-10-10 at 14:27 +0100, Thom Brown wrote:
> I don't know if this has already been discussed, but can you explain
> the following:
>
> postgres=# select '[1,8]'::int4range;
> int4range
> -----------
> [1,9)
> (1 row)
>
> It seems unintuitive to represent a discrete range using an exclusive
> upper bound. While I agree that the value itself is correct, it's
> representation looks odd. Is it necessary?
The "canonicalize" function (specified at type creation time) allows you
to specify the canonical output representation. So, I can change the
canonical form for discrete ranges to use '[]' notation if we think
that's more expected.
But then "int4range(1,8)" would still mean "int4range(1,8,'[)')" and
therefore '[1,7]'. I used to have a "default_flags" parameter that could
also be specified at type creation time that would control the default
third parameter (the parameter that controls inclusivity) of the
constructor. However, I removed the "default_flags" parameter because,
as Florian pointed out, it's better to have a consistent output from the
constructor.
I'm open to suggestions, including potentially bringing back
"default_flags".
Regards,
Jeff Davis
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-10-10 16:53:54 | Re: Range Types - typo + NULL string constructor |
Previous Message | Robert Haas | 2011-10-10 16:42:35 | Re: WIP: Join push-down for foreign tables |