From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Sergei(dot)Agalakov(at)gmail(dot)com |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #8939: Cast to range type fails due to whitespaces in the text string |
Date: | 2014-01-23 20:23:54 |
Message-ID: | 8724.1390508634@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Sergei(dot)Agalakov(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | nghia.le | 2014-01-24 01:03:52 | BUG #8943: optimizer appears to not be efficient when there is little data in the query results |
Previous Message | Marcus Overheu | 2014-01-23 19:44:12 | Re: BUG #8934: value != ANY (uuid[]) AND expr does not work in all cases |