Re: Remaining dependency on setlocale()

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Daniel Verite <daniel(at)manitou-mail(dot)org>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Remaining dependency on setlocale()
Date: 2025-10-30 20:53:43
Message-ID: 26caf0ee08d9978eba107e2928c3dd164608afb8.camel@j-davis.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 2025-10-30 at 21:41 +0100, Daniel Verite wrote:
> What about code in extensions? AFAIU a user can control the
> locale in effect by setting the LC_CTYPE argument of
> CREATE DATABASE, which ends up in the environment
> of backends serving that database.
> If it's forced to "C", how can an extension use locale-aware
> libc functions?

Extensions often need to be updated for a new major version.

The extension should call pg_database_locale(), and pass that to a
function exposed in pg_locale.h. A recent commit exposed pg_iswalpha(),
etc., so there's a reasonable set of functions that should be suitable
for most purposes.

If it's not available in pg_locale.h, or the extension really needs to
use a different LC_CTYPE for some reason, it can use an _l() variant of
the function.

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2025-10-30 21:02:24 Re: another autovacuum scheduling thread
Previous Message Daniel Verite 2025-10-30 20:41:50 Re: Remaining dependency on setlocale()