From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Tightening isspace() tests where behavior should match SQL parser |
Date: | 2017-05-23 20:44:23 |
Message-ID: | 1716.1495572263@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <hlinnaka(at)iki(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Larry Rosenman | 2017-05-23 21:37:41 | FW: PGBuildfarm member peripatus Branch REL9_2_STABLE Status changed from PLCheck-C failure to OK |
Previous Message | Beena Emerson | 2017-05-23 19:22:21 | Re: Default Partition for Range |