Re: simplify regular expression locale global variables
От | Andreas Karlsson |
---|---|
Тема | Re: simplify regular expression locale global variables |
Дата | |
Msg-id | 2b40d22a-b040-4c2e-8f42-6b6d6a896454@proxel.se обсуждение исходный текст |
Список | pgsql-hackers |
On 10/15/24 8:12 AM, Peter Eisentraut wrote: > We currently have > > static PG_Locale_Strategy pg_regex_strategy; > static pg_locale_t pg_regex_locale; > static Oid pg_regex_collation; > > 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. Jeff Davis has a patch which also fixes this while refactoring other stuff too which I prefer over your patch since it also cleans up the collation code in general. https://www.postgresql.org/message-id/2830211e1b6e6a2e26d845780b03e125281ea17b.camel%40j-davis.com > The second patch removes a call to pg_set_regex_collation() that I think > is unnecessary. > > The third patch adds a pg_unset_regex_collation() call that undoes what > pg_set_regex_collation() does. I mainly used this to verify the second > patch, but maybe it's also useful on its own, not sure. > > (I don't have any plans to get rid of the remaining global variable. > That would certainly be nice from an intellectual point of view, but > fiddling this into the regular expression code looks quite messy. In > any case, it's probably easier with one variable instead of three, if > someone wants to try.) I have not looked at your other two patches yet. Andreas
В списке pgsql-hackers по дате отправления: