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: <08ea5ab0-5f9a-f80a-cb2f-79058e581199@iki.fi>
References: <10129.1495302480@sss.pgh.pa.us>
 <08ea5ab0-5f9a-f80a-cb2f-79058e581199@iki.fi>
Comments: In-reply-to Heikki Linnakangas <hlinnaka@iki.fi>
	message dated "Tue, 23 May 2017 06:56:58 -0400"
Date: Tue, 23 May 2017 16:44:23 -0400
Message-ID: <1716.1495572263@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Heikki Linnakangas <hlinnaka@iki.fi> writes:
> On 05/20/2017 01:48 PM, Tom Lane wrote:
>> Attached is a proposed patch.  I'm vacillating on whether to
>> back-patch this --- it will fix a reported bug, but it seems
>> at least somewhat conceivable that it will also break cases
>> that were working acceptably before.  Thoughts?

> +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.  But that
seems like a very narrow use-case, and probably not enough to justify
the misbehavior you might get in multi-byte character sets.

A compromise possibly worth considering is to apply isspace() only in
single-byte encodings.  I think that's more complication than it's
worth, but others might think differently.

			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