Arbitrary whitespace restrictions on range types

On 18 December 2012 23:31, Josh Berkus <josh@agliodbs.com> wrote:

Jeff, Hackers:

Is there a strong reason why this has to error?

Having taken a look at the range I/O routines, I surmise that it was
just easier to write range_parse() such that whitespace is included
within <string> tokens:

* Whitespace before or after <range> is ignored. Whitespace within a <string>
* is taken literally and becomes part of the input string for that bound.

I think that escaping the underlying literal values for parsing is a
surprisingly difficult task, so I can see why the implementation would
shrug in this case. This behaviour may be astonishing, but that
doesn't make it a POLA violation. I don't have time to check now, but
I'm pretty sure that doing something else would break a whole bunch of
other common cases.

--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

On Wed, 2012-12-19 at 00:06 +0000, Peter Geoghegan wrote:

On 18 December 2012 23:31, Josh Berkus <josh@agliodbs.com> wrote:

Jeff, Hackers:

Is there a strong reason why this has to error?

Having taken a look at the range I/O routines, I surmise that it was
just easier to write range_parse() such that whitespace is included
within <string> tokens:

There was some discussion about it, and the decision was made to match
record literal parsing for the sake of consistency. In a record literal,
spaces are considered to be a part of the value, so they are for range
types, as well.

Regards,
Jeff Davis

--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs