Обсуждение: BUG #8939: Cast to range type fails due to whitespaces in the text string

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.

Sergei.Agalakov@gmail.com writes:
> 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

I see no bug here.  If you're omitting a value, you can't put some random
whitespace there instead.  The documentation seems clear enough about that
to me.

> 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.

Don't insert any made-up whitespace.  What's so hard about that?

            regards, tom lane