From: Tom Lane <tgl@sss.pgh.pa.us>
To: Heikki Linnakangas <hlinnaka@iki.fi>
cc: pgsql-hackers@postgresql.org
Subject: Re: Tightening isspace() tests where behavior should match SQL parser
In-reply-to: <1716.1495572263@sss.pgh.pa.us>
References: <10129.1495302480@sss.pgh.pa.us>
 <08ea5ab0-5f9a-f80a-cb2f-79058e581199@iki.fi> <1716.1495572263@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Tue, 23 May 2017 16:44:23 -0400"
Date: Wed, 24 May 2017 15:34:07 -0400
Message-ID: <2848.1495654447@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

I wrote:
> Heikki Linnakangas <hlinnaka@iki.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.

Hence, applied and back-patched.

			regards, tom lane


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