BUG #8939: Cast to range type fails due to whitespaces in the text string

From: Sergei(dot)Agalakov(at)gmail(dot)com
To: pgsql-bugs(at)postgresql(dot)org
Subject: BUG #8939: Cast to range type fails due to whitespaces in the text string
Date: 2014-01-23 17:27:03
Message-ID: 20140123172703.26702.69411@wrigleys.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

The following bug has been logged on the website:

Bug reference: 8939
Logged by: Sergei Agalakov
Email address: Sergei(dot)Agalakov(at)gmail(dot)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.

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Alvaro Herrera 2014-01-23 17:48:29 Re: Re: [BUGS] BUG #7873: pg_restore --clean tries to drop tables that don't exist
Previous Message Alvaro Herrera 2014-01-23 17:11:24 Re: BUG #8934: value != ANY (uuid[]) AND expr does not work in all cases