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

2017-06-09 Thread Peter Eisentraut
On 5/24/17 15:34, Tom Lane wrote: > I wrote: >> Heikki Linnakangas 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

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

2017-05-24 Thread Tom Lane
I wrote: > Heikki Linnakangas 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

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

2017-05-23 Thread Tom Lane
Heikki Linnakangas 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

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

2017-05-23 Thread Heikki Linnakangas
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

[HACKERS] Tightening isspace() tests where behavior should match SQL parser

2017-05-20 Thread Tom Lane
The proximate cause of bug #14662, https://www.postgresql.org/message-id/flat/20170519162316.29945.5021%40wrigleys.postgresql.org appears to be that SplitIdentifierString's isspace() checks are identifying some bytes of a multibyte character as spaces. It's not quite clear to me whether there's