Re: tiny step toward threading: reduce dependence on setlocale()

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Andreas Karlsson <andreas(at)proxel(dot)se>, Peter Eisentraut <peter(at)eisentraut(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: tiny step toward threading: reduce dependence on setlocale()
Date: 2024-07-26 20:35:54
Message-ID: 59ea4275d75829a055fc55d8fe139eb85764cf2b.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 2024-07-26 at 19:38 +0200, Andreas Karlsson wrote:
> Nice refactoring!
>
> Two small comments about CheckMyDatabase().
>
> - Shouldn't we look at the default_locale.ctype_is_c when setting
> database_ctype_is_c instead of doing a strcmp()? or maybe we should
> even
> remove the global variable and always look at the default_locale?

database_ctype_is_c refers to the LC_CTYPE environment of the database
-- pg_database.datctype. default_locale.ctype_is_c is the ctype of the
database's default collation.

Confusing, I know, but it matters for a few things that still depend on
the LC_CTYPE, such as tsearch and maybe a few extensions. See
f413941f41.

> - I think that the lookup of Anum_pg_database_datlocale could be done
> later in the code since it is not needed when we use a libc locale.
> E.g.
> as below.

Done, thank you.

> Also is there any reaosn you do not squash th 4th and the 6th patch?

Done. I had to rearrange the patch ordering a bit because prior to the
cache refactoring patch, it's unsafe to call
pg_newlocale_from_collation() without checking lc_collate_is_c() or
lc_ctype_is_c() first.

Regards,
Jeff Davis

Attachment Content-Type Size
v4-0001-Make-database-default-collation-internal-to-pg_lo.patch text/x-patch 6.5 KB
v4-0002-Make-database-collation-pg_locale_t-always-non-NU.patch text/x-patch 7.5 KB
v4-0003-Refactor-collation-cache.patch text/x-patch 11.1 KB
v4-0004-ts_locale.c-do-not-use-NULL-to-mean-the-database-.patch text/x-patch 3.5 KB
v4-0005-Remove-support-for-null-pg_locale_t.patch text/x-patch 29.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2024-07-26 20:36:20 Re: pg_upgrade failing for 200+ million Large Objects
Previous Message Nathan Bossart 2024-07-26 20:32:12 Re: problems with "Shared Memory and Semaphores" section of docs