Re: simplify regular expression locale global variables

Peter Eisentraut <peter@eisentraut.org>

From: Peter Eisentraut <peter@eisentraut.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-10-21T05:50:44Z
Lists: pgsql-hackers

Attachments

On 15.10.24 17:04, Tom Lane wrote:
> Peter Eisentraut <peter@eisentraut.org> writes:
>> but after the recent improvements to pg_locale_t handling, we don't need
>> all three anymore.  All the information we have is contained in
>> pg_locale_t, so we just need to keep that one.  This allows us to
>> structure the locale-using regular expression code more similar to other
>> locale-using code, mainly by provider, avoiding another layer that is
>> specific only to the regular expression code.  The first patch
>> implements that.
> 
> I didn't read that patch in detail; somebody who's more familiar than
> I with the recent locale-code changes ought to read it and confirm
> that no subtle behavioral changes are sneaking in.  But +1 for
> concept.

Ok, I'll wait for someone to give it a detailed review.

> 
>> The second patch removes a call to pg_set_regex_collation() that I think
>> is unnecessary.
> 
> I think this is actively wrong.  pg_regprefix is engaged in> determining whether there's a fixed prefix of the regex, which
> at least involves a sort of symbolic execution.  As an example,
> whether '^x' has a fixed prefix surely depends on whether the locale
> is case-insensitive.

Hmm, okay, I'll leave this out for now and maybe come back to it later. 
For the time being, here is a new patch with this part omitted.

Commits

  1. Remove pg_regex_collation