Re: missing possibility to use alternative translated month names in to_char function

From: Bernd Reiß <bd_reiss(at)gmx(dot)at>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: missing possibility to use alternative translated month names in to_char function
Date: 2026-08-23 06:31:56
Message-ID: df181efc-666d-46d0-8dc0-e78e99e424b0@gmx.at
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 23/08/2026 07:30, Pavel Stehule wrote:
> Hi
>
> pá 21. 8. 2026 v 18:56 odesílatel Bernd Reiß <bd_reiss(at)gmx(dot)at> napsal:
>
> 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(at)gmx(dot)at
> <mailto:bd_reiss(at)gmx(dot)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);
>
>
> this code is removed in new version
>
>
> >
> > Please check updated patch
> >
>
> With the if statements cleaned up this is a +1 for Ready for
> Committer from me.
>
>
> Regards
>
> Pavel

Patch applies cleanly now on HEAD. New changes LGTM. Compiles without
problems and
regression tests are all green. I am moving this to Ready for Reviewer.

Best
Bernd

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhijie Hou (Fujitsu) 2026-08-23 06:37:17 RE: MERGE/SPLIT PARTITIONS issues/questions
Previous Message Pavel Stehule 2026-08-23 05:30:13 Re: missing possibility to use alternative translated month names in to_char function