On 17.12.24 19:10, Jeff Davis wrote:
On Tue, 2024-12-17 at 13:14 +0100, Peter Eisentraut wrote:
I think we will need to keep the global LC_CTYPE setting set to
something useful, for example so that system error messages come out
in
the right encoding.
Do we need to rely on the global LC_CTYPE
On Tue, 2024-12-17 at 13:14 +0100, Peter Eisentraut wrote:
> I think we will need to keep the global LC_CTYPE setting set to
> something useful, for example so that system error messages come out
> in
> the right encoding.
Do we need to rely on the global LC_CTYPE setting? We already use
bind_te
On 13.12.24 10:44, Thomas Munro wrote:
On Fri, Dec 13, 2024 at 8:22 AM Jeff Davis wrote:
On Wed, 2024-08-14 at 12:00 -0700, Jeff Davis wrote:
On Wed, 2024-08-14 at 14:31 +1200, Thomas Munro wrote:
1. The process global locale is always "C". If you ever call
uselocale(), it can only be for s
On Fri, Dec 13, 2024 at 8:22 AM Jeff Davis wrote:
> On Wed, 2024-08-14 at 12:00 -0700, Jeff Davis wrote:
> > On Wed, 2024-08-14 at 14:31 +1200, Thomas Munro wrote:
> > > 1. The process global locale is always "C". If you ever call
> > > uselocale(), it can only be for short stretches, and you ha
On Wed, 2024-08-14 at 12:00 -0700, Jeff Davis wrote:
> On Wed, 2024-08-14 at 14:31 +1200, Thomas Munro wrote:
> > 1. The process global locale is always "C". If you ever call
> > uselocale(), it can only be for short stretches, and you have to
> > restore it straight after; perhaps it is only eve
On 8/9/24 8:24 PM, Jeff Davis wrote:
On Fri, 2024-08-09 at 13:41 +0200, Andreas Karlsson wrote:
I am leaning towards that we should write our own pure ascii
functions
for this.
That makes sense for a lot of call sites, but it could cause breakage
if we aren't careful.
Since we do not suppo
On Fri, Aug 16, 2024 at 9:09 AM Thomas Munro wrote:
> On Fri, Aug 16, 2024 at 1:25 AM Peter Eisentraut wrote:
> > It should just be initdb doing that and then initializing the server
> > with concrete values based on that.
>
> Right.
>
> > I guess technically some of these GUC settings default to
On Fri, Aug 16, 2024 at 1:25 AM Peter Eisentraut wrote:
> On 15.08.24 00:43, Thomas Munro wrote:
> > "" is a problem however... the special value for "native environment"
> > is returned as a real locale name, which we probably still need in
> > places. We could change that to newlocale("") + que
On 15.08.24 00:43, Thomas Munro wrote:
"" is a problem however... the special value for "native environment"
is returned as a real locale name, which we probably still need in
places. We could change that to newlocale("") + query instead, but
Where do we need that in the server?
It should jus
On Thu, Aug 15, 2024 at 11:00 AM Jeff Davis wrote:
> On Thu, 2024-08-15 at 10:43 +1200, Thomas Munro wrote:
> > So I think the solution could perhaps be something like: in some
> > early
> > startup phase before there are any threads, we nail down all the
> > locale categories to "C" (or whatever
On Thu, 2024-08-15 at 10:43 +1200, Thomas Munro wrote:
> So I think the solution could perhaps be something like: in some
> early
> startup phase before there are any threads, we nail down all the
> locale categories to "C" (or whatever we decide on for the permanent
> global locale), and also quer
On Wed, Aug 7, 2024 at 7:07 PM Thomas Munro wrote:
> On Wed, Aug 7, 2024 at 10:23 AM Tom Lane wrote:
> > Jeff Davis writes:
> > > 2. I don't see a good way to canonicalize a locale name, like in
> > > check_locale(), which uses the result of setlocale().
> >
> > What I can tell you about that is
On Wed, 2024-08-14 at 14:31 +1200, Thomas Munro wrote:
> 1. The process global locale is always "C". If you ever call
> uselocale(), it can only be for short stretches, and you have to
> restore it straight after; perhaps it is only ever used in
> replacement
> _l() functions for systems that lac
On Wed, Aug 14, 2024 at 1:05 PM Jeff Davis wrote:
> The only alternative is to essentially ban the use of non-_l variants,
> which is fine I suppose, but causes a fair amount of code churn.
Let's zoom out a bit and consider some ways we could set up the
process, threads and individual calls:
1.
On Sat, 2024-08-10 at 09:42 +1200, Thomas Munro wrote:
> The NetBSD situation is more vexing. I was trying to find out if
> someone is working on it and unfortunately it looks like there is a
> principled stand against adding it:
>
> https://mail-index.netbsd.org/tech-userlevel/2015/12/28/msg0095
On Tue, Aug 13, 2024 at 10:43 AM Thomas Munro wrote:
> I'll try this in a bit unless someone else has better ideas or plans
> for this part... sorry for the drip-feeding.
And done, see commitfest entry #5170.
On Mon, Aug 12, 2024 at 4:53 PM Thomas Munro wrote:
> ... though if we wanted to replace all use of localeconv and struct
> lconv with nl_langinfo_l() calls,
Gah. I realised while trying the above that you can't really replace
localeconv() with nl_langinfo_l() as the GNU documentation recommends
On Mon, Aug 12, 2024 at 3:24 PM Thomas Munro wrote:
> 1. The nl_langinfo() call in pg_get_encoding_from_locale(), can
> probably be changed to nl_langinfo_l() (it is everywhere we currently
> care about except Windows, which has a different already-thread-safe
> alternative ...
... though if we
On Thu, Aug 8, 2024 at 5:16 AM Jeff Davis wrote:
> On Wed, 2024-08-07 at 19:07 +1200, Thomas Munro wrote:
> > How far can we get by using more _l() functions?
>
> There are a ton of calls to, for example, isspace(), used mostly for
> parsing.
>
> I wouldn't expect a lot of differences in behavior
I've posted a new attempt at ripping those ECPG setlocales() out on
the other thread that had the earlier version and discussion:
https://www.postgresql.org/message-id/CA%2BhUKG%2BYv%2Bps%3DnS2T8SS1UDU%3DiySHSr4sGHYiYGkPTpZx6Ooww%40mail.gmail.com
On Wed, Aug 7, 2024 at 7:07 PM Thomas Munro wrote:
> On Wed, Aug 7, 2024 at 10:23 AM Tom Lane wrote:
> > Jeff Davis writes:
> > > But there are a couple problems:
> >
> > > 1. I don't think it's supported on Windows.
> >
> > Can't help with that, but surely Windows has some thread-safe way.
>
>
Hi,
On Fri, 2024-08-09 at 15:16 -0500, Tristan Partin wrote:
> Hey Jeff,
>
> See this thread[0] for some work that I had previously done. Feel
> free
> to take it over, or we could collaborate.
>
> [0]:
> https://www.postgresql.org/message-id/cwmw5ozbwj10.1yflqwsue5...@neon.tech
Sounds good, s
On Tue Aug 6, 2024 at 5:00 PM CDT, Jeff Davis wrote:
After some previous work here:
https://postgr.es/m/89475ee5487d795124f4e25118ea8f1853edb8cb.ca...@j-davis.com
we are less dependent on setlocale(), but it's still not completely
gone.
setlocale() counts as thread-unsafe, so it would be nice
On Fri, 2024-08-09 at 13:41 +0200, Andreas Karlsson wrote:
> I am leaning towards that we should write our own pure ascii
> functions
> for this.
That makes sense for a lot of call sites, but it could cause breakage
if we aren't careful.
> Since we do not support any non-ascii compatible encodi
On 8/8/24 12:45 AM, Jeff Davis wrote:
My point was just that there are a lot of those call sites (especially
for isspace()) in various parsers. It feels like a lot of code churn to
change all of them, when a lot of them seem to be intended for ascii
anyway.
And where do we get the locale_t struc
On Wed, 2024-08-07 at 13:28 -0400, Joe Conway wrote:
> FWIW I see all of these in glibc:
>
> isalnum_l, isalpha_l, isascii_l, isblank_l, iscntrl_l, isdigit_l,
> isgraph_l, islower_l, isprint_l, ispunct_l, isspace_l, isupper_l,
> isxdigit_l
My point was just that there are a lot of those call s
On Thu, Aug 8, 2024 at 6:18 AM Robert Haas wrote:
> On Wed, Aug 7, 2024 at 1:29 PM Joe Conway wrote:
> > FWIW I see all of these in glibc:
> >
> > isalnum_l, isalpha_l, isascii_l, isblank_l, iscntrl_l, isdigit_l,
> > isgraph_l, islower_l, isprint_l, ispunct_l, isspace_l, isupper_l,
> > isxdigit_
On Thu, Aug 8, 2024 at 5:16 AM Jeff Davis wrote:
> There are a ton of calls to, for example, isspace(), used mostly for
> parsing.
>
> I wouldn't expect a lot of differences in behavior from locale to
> locale, like might be the case with iswspace(), but behavior can be
> different at least in the
On Wed, Aug 7, 2024 at 1:29 PM Joe Conway wrote:
> FWIW I see all of these in glibc:
>
> isalnum_l, isalpha_l, isascii_l, isblank_l, iscntrl_l, isdigit_l,
> isgraph_l, islower_l, isprint_l, ispunct_l, isspace_l, isupper_l,
> isxdigit_l
On my MacBook (Ventura, 13.6.7), I see all of these except f
On 8/7/24 13:16, Jeff Davis wrote:
On Wed, 2024-08-07 at 19:07 +1200, Thomas Munro wrote:
How far can we get by using more _l() functions?
There are a ton of calls to, for example, isspace(), used mostly for
parsing.
I wouldn't expect a lot of differences in behavior from locale to
locale, li
On Wed, 2024-08-07 at 19:07 +1200, Thomas Munro wrote:
> How far can we get by using more _l() functions?
There are a ton of calls to, for example, isspace(), used mostly for
parsing.
I wouldn't expect a lot of differences in behavior from locale to
locale, like might be the case with iswspace(),
On Wed, Aug 7, 2024 at 9:42 AM Joe Conway wrote:
> I guess in many/most places we use atoi we don't care, but maybe it
> matters for some?
I think we should move in the direction of replacing atoi() calls with
strtol() and actually checking for errors. In many places where use
atoi(), it's unlike
On 8/7/24 03:07, Thomas Munro wrote:
How far can we get by using more _l() functions? For example, [1]
shows a use of strftime() that I think can be converted to
strftime_l() so that it doesn't depend on setlocale(). Since POSIX
doesn't specify every obvious _l function, we might need to provid
On Wed, Aug 7, 2024 at 10:23 AM Tom Lane wrote:
> Jeff Davis writes:
> > But there are a couple problems:
>
> > 1. I don't think it's supported on Windows.
>
> Can't help with that, but surely Windows has some thread-safe way.
It does. It's not exactly the same, instead there is a thing you can
Jeff Davis writes:
> But there are a couple problems:
> 1. I don't think it's supported on Windows.
Can't help with that, but surely Windows has some thread-safe way.
> 2. I don't see a good way to canonicalize a locale name, like in
> check_locale(), which uses the result of setlocale().
What
35 matches
Mail list logo
