Thread: Re: simplify regular expression locale global variables

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 = {.ctype_is_c = true};
> +
> +        locale = &dummy_locale;
>      }
>      else
>      {
> @@ -264,121 +253,80 @@ pg_set_regex_collation(Oid collation)
>              ereport(ERROR,
>                      (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
>                       errmsg("nondeterministic collations are not supported for regular expressions")));
> [...]
>      }
>  
>      pg_regex_locale = locale;
>  }

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 isn't
kosher.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/

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().
>>            */
>> +        static struct pg_locale_struct dummy_locale = {.ctype_is_c = true};
>> +
>> +        locale = &dummy_locale;
>>       }
>>       else
>>       {
>> @@ -264,121 +253,80 @@ pg_set_regex_collation(Oid collation)
>>               ereport(ERROR,
>>                       (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
>>                        errmsg("nondeterministic collations are not supported for regular expressions")));
>> [...]
>>       }
>>   
>>       pg_regex_locale = locale;
>>   }
> 
> 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 isn't
> kosher.

I think this must be okay.  Some classic non-thread-safe C library 
functions essentially work that way, e.g.,

char *strerror(int errnum)
{
     static char buf[...];
     strcpy(buf, ....);
     return buf;
}

and then you can use the return pointer wherever you want.

Alvaro Herrera <alvherre@alvh.no-ip.org> 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 isn't
> kosher.

We use function-local statics in other places, and I have never
heard that it's not kosher.  There would be little point in
declaring such a variable static at all if that didn't cause
it to have persistent storage.

            regards, tom lane