Hi,
On 23/08/2026 07:30, Pavel Stehule wrote:
Hi
pá 21. 8. 2026 v 18:56 odesílatel Bernd Reiß <[email protected]> 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ß <[email protected]
<mailto:[email protected]>> 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
