Re: Tightening isspace() tests where behavior should match SQL parser

On 5/24/17 15:34, Tom Lane wrote:
> I wrote:
>> Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
>>> +1 for back-patching. If I understand correctly, it would change the
>>> behavior when you pass a string with non-ASCII leading or trailing
>>> whitespace characters to those functions. I suppose that can happen, but
>>> it's only pure luck if the current code happens to work in that case.
>
>> Well, it'd work properly for e.g. no-break space in LATINn.
>
> Actually, it's dubious that treating no-break space as whitespace is
> correct at all in these use-cases. The core scanner would think it's
> an identifier character, so it's not impossible that somebody would
> consider it cute to write &nbsp; as part of a SQL identifier. If
> the core scanner accepts that, so must these functions.

The SQL standard might permit non-breaking spaces or similar things as
token delimiters, so it could be legitimate to look into changing that
sometime. But in any case it should be consistent, so it's correct to
make this change now.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services