ne 23. 8. 2026 v 12:37 odesílatel <[email protected]> napsal: > Ah, my bad. Meant to say Committer, of course :) >
Thank you :) Pavel > > Bernd > > Sent with Spark <https://sparkmailapp.com/source?from=signature> > On 23 Aug 2026 at 12:32 +0200, Pavel Stehule <[email protected]>, > wrote: > > > > ne 23. 8. 2026 v 8:32 odesílatel Bernd Reiß <[email protected]> napsal: > >> 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. >> > > you are a reviewer :-) > > Pavel > >> >> Best >> Bernd >> >
