Re: [HACKERS] Tightening isspace() tests where behavior should match SQL parser - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Tightening isspace() tests where behavior should match SQL parser
Date
Msg-id 2848.1495654447@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Tightening isspace() tests where behavior should match SQL parser  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Tightening isspace() tests where behavior should matchSQL parser  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
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   as part of a SQL identifier.  If
the core scanner accepts that, so must these functions.

Hence, applied and back-patched.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] ALTER SUBSCRIPTION ..SET PUBLICATION refreshis not throwing error.
Next
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] ALTER SUBSCRIPTION ..SET PUBLICATION refreshis not throwing error.