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
- v2-0001-Remove-pg_regex_collation-and-pg_regex_strategy.patch (text/plain) patch v2-0001
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
-
Remove pg_regex_collation
- 792b2c7e6d92 18.0 landed