The following bug has been logged on the website:
Bug reference: 8939
Logged by: Sergei Agalakov
Email address: Sergei.Agalakov@gmail.com
PostgreSQL version: 9.3.2
Operating system: Windows
Description:
According to documentation
http://www.postgresql.org/docs/9.3/interactive/rangetypes.html paragraph
8.17.5. Range Input/Output
"Whitespace is allowed before and after the range value, but any whitespace
between the parentheses or brackets is taken as part of the lower or upper
bound value. (Depending on the element type, it might or might not be
significant.)"
The real behavior is different for bounded and unbounded ranges:
SELECT '[10,)'::int4range; -- OK
SELECT '[10, )'::int4range; -- Fails
SELECT '[10,12 )'::int4range; -- OK
SELECT '(, 10]'::int4range; -- OK
SELECT '(,10 )'::int4range; -- OK
SELECT '( ,10)'::int4range; -- Fails
SELECT '( 8,10)'::int4range; -- OK
Constructor works predictably all the time trimming whitespaces:
SELECT int4range( 10 , null , '[)' ); -- OK
I would expect that for range types where white spaces can't be significant
for evaluating elements they would be trimmed before evaluating a SQL
statement with casting to a range type. Currently an implementation of
casting to range types is too peaky to the exact syntax of the text string.
