On 5/24/17 15:34, Tom Lane wrote: > I wrote: >> Heikki Linnakangas <hlinn...@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.
The SQL standard might permit non-breaking spaces or similar things as token delimiters, so it could be legitimate to look into changing that sometime. But in any case it should be consistent, so it's correct to make this change now. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
