Re: fixing tsearch locale support

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: fixing tsearch locale support
Date: 2024-12-13 17:07:54
Message-ID: aa8d8a056997297fdb60a82db01c280c9e71f4ba.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 2024-12-13 at 07:16 +0100, Peter Eisentraut wrote:
> isdigit() and isspace() in particular are widely used throughout the
> backend code without such concerns.  I think the assumption is that
> this
> is not a problem in practice: For multibyte encodings, these
> functions
> would only be able to process the ASCII subset, and the character
> classification of that should be consistent across all locales.  For
> single-byte encodings, among the encodings that PostgreSQL supports,
> I
> don't think any of them actually provide non-ASCII digits or space
> characters.

OK, that's fine with me for this patch series.

Eventually though, I think we should have built-in versions of these
ASCII functions. Even if there's no actual problem, it would more
clearly indicate that we only care about ASCII at that particular call
site, and eliminate questions about what libc might do on some platform
for some encoding/locale combination. It would also make it easier to
search for locale-sensitive functions in the codebase.

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2024-12-13 19:10:13 pg_attribute_noreturn(), MSVC, C11
Previous Message Pavel Stehule 2024-12-13 16:46:44 Re: OLEDB provider for PostgreSQL