Re: simplify regular expression locale global variables

2024-12-04 Thread Peter Eisentraut
On 03.12.24 20:19, Jeff Davis wrote: On Tue, 2024-12-03 at 17:06 +0100, Peter Eisentraut wrote: But it doesn't remove pg_regex_collation, only pg_regex_strategy.  So I have split my v2 into two patches, the first removes pg_regex_collation and the second removes pg_regex_strategy.  The first pat

Re: simplify regular expression locale global variables

2024-12-03 Thread Jeff Davis
On Tue, 2024-12-03 at 17:06 +0100, Peter Eisentraut wrote: > But it doesn't remove pg_regex_collation, only pg_regex_strategy.  So > I > have split my v2 into two patches, the first removes > pg_regex_collation > and the second removes pg_regex_strategy.  The first patch is useful > on > its own

Re: simplify regular expression locale global variables

2024-12-03 Thread Peter Eisentraut
On 25.10.24 10:16, Andreas Karlsson wrote: 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, w

Re: simplify regular expression locale global variables

2024-10-25 Thread Andreas Karlsson
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 in

Re: simplify regular expression locale global variables

2024-10-20 Thread Peter Eisentraut
On 15.10.24 17:04, Tom Lane wrote: Peter Eisentraut 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 regul

Re: simplify regular expression locale global variables

2024-10-15 Thread Tom Lane
Peter Eisentraut 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 sim

Re: simplify regular expression locale global variables

2024-10-15 Thread Tom Lane
Alvaro Herrera writes: > Hmm, is it valid to make pg_regex_locale point to a function-local > static here? The lifetime of this static is not clear to me, and I > think this pattern works with at least some compilers, but I remember > comments on previous patch review threads that this pattern is

Re: simplify regular expression locale global variables

2024-10-15 Thread Peter Eisentraut
On 15.10.24 12:08, Alvaro Herrera wrote: On 2024-Oct-15, Peter Eisentraut wrote: @@ -253,8 +241,9 @@ pg_set_regex_collation(Oid collation) * catalog access is available, so we can't call * pg_newlocale_from_collation(). */ + stati

Re: simplify regular expression locale global variables

2024-10-15 Thread Alvaro Herrera
On 2024-Oct-15, Peter Eisentraut wrote: > @@ -253,8 +241,9 @@ pg_set_regex_collation(Oid collation) >* catalog access is available, so we can't call >* pg_newlocale_from_collation(). >*/ > + static struct pg_locale_struct dummy_locale = {

simplify regular expression locale global variables

2024-10-14 Thread Peter Eisentraut
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, s