Feedback-ID: ia2694551:Fastmail
Date: Tue, 15 Oct 2024 12:08:01 +0200
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: simplify regular expression locale global variables
Message-ID: <202410151008.jnqrposiz6p5@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <b1b92ae1-2e06-4619-a87a-4b4858e547ec@eisentraut.org>
Archived-At: <https://www.postgresql.org/message-id/202410151008.jnqrposiz6p5%40alvherre.pgsql>
Precedence: bulk

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/