Re: missing possibility to use alternative translated month names in to_char function - Mailing list pgsql-hackers

From Bernd Reiß
Subject Re: missing possibility to use alternative translated month names in to_char function
Date
Msg-id bd61f759-fc35-449f-b168-b0ea927a3e25@gmx.at
Whole thread
In response to Re: missing possibility to use alternative translated month names in to_char function  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: glob support in extension_control_path/dynamic_library_path?
Re: missing possibility to use alternative translated month names in to_char function
List pgsql-hackers
Hi Pavel,

On 8/18/26 8:47 PM, Pavel Stehule wrote:
> Hi
>
> so 15. 8. 2026 v 14:03 odesílatel Bernd Reiß <bd_reiss@gmx.at <mailto:bd_reiss@gmx.at>> napsal:
>
>     Hi again,
>
>     thanks for the updated patch.
>     > TAMMON is not implemented, because glibc doesn't provide an
>     > alternative form for abbreviated month names.
>     > It is a question if it is better to raise an error, return a non
>     > alternative name or just ignore this flag. I have not strong
>     > opinion about this. Inside DCH_to_char the prefix TM is ignored when
>     > it is not used. So I did the same.
>     The Locale standard actually mentions abbreviated alternative month
>     names as
>     "ab_alt_mon" (see [1]). I tested this by setting your TAMMONTH strftime
>     call to '%Ob'.
>     If we set the locale to Russian and call the function for May this
>     actually returns
>     an abbreviated version of the month name:
>
>     Breakpoint 1, cache_locale_time () at pg_locale.c:772
>     772           if (strftime_l(bufptr, MAX_L10N_DATA, "%Ob", timeinfo,
>     locale) <= 0)
>     (gdb) n
>     774                     bufptr += MAX_L10N_DATA;
>     (gdb) print bufptr
>     $4 = 0x7ffde4554630 "май"
>
>     Compared to the TMMON form of May in Russian this actually makes a
>     difference:
>
>     postgres=# set lc_time='ru_RU.UTF8';
>     SET
>     postgres=# select to_char('2026-05-01'::date, 'TMMON');
>       to_char
>     ---------
>       МАЯ
>     (1 row)
>
>     postgres=# select to_char('2026-05-01'::date, 'TAMMONTH');
>       to_char
>     ---------
>       МАЙ
>     (1 row)
>
>     Again, TAMMONTH uses %Ob here. So I would argue for implementing the
>     abbreviated
>     forms too.
>
>
> I implemented it - please check

LGTM. I compiled it and it works as expected. I also like the introduction of
the get_localized_*_months functions. However, this leads to suffix_len being
declared and set but never used in the DCH_MONTH, DCH_Month, and DCH_month
cases (as well as for the abbreviated equivalents) in DCH_from_char. Passing
NULL and guarding in the functions would be an option to avoid this. However,
I don't feel strongly about this.

In DCH_to_char I think you forgot to refactor this if statement for the
MON/Mon/mon cases?

          if (strlen(str) <= (n->key->len + TM_SUFFIX_LEN) * DCH_MAX_ITEM_SIZ)
            strcpy(s, str);

>
> Please check updated patch
>

With the if statements cleaned up this is a +1 for Ready for Committer from me.

Best
Bernd



pgsql-hackers by date:

Previous
From: Andrey Borodin
Date:
Subject: Re: Fix XLogFileReadAnyTLI silently applying divergent WAL from wrong timeline
Next
From: Bharath Rupireddy
Date:
Subject: Re: Introduce XID age based replication slot invalidation