On Sat, Jan 5, 2019 at 5:21 PM Tomas Vondra <tomas.von...@2ndquadrant.com> wrote: > On 1/5/19 1:11 AM, Alexander Korotkov wrote: > > On Tue, Dec 4, 2018 at 2:23 AM Nikita Glukhov <n.glu...@postgrespro.ru> > > wrote: > >> 2) We define both DCH_FF# and DCH_ff#, but we never ever use the > >> lower-case version. Heck, it's not mentioned even in DCH_keywords, which > >> does this: > >> > >> ... > >> {"FF1", 3, DCH_FF1, false, FROM_CHAR_DATE_NONE}, /* F */ > >> ... > >> {"ff1", 3, DCH_FF1, false, FROM_CHAR_DATE_NONE}, /* F */ > >> ... > >> > >> Compare that to DCH_DAY, DCH_Day and DCH_day, mapped to "DAY", "Day" and > >> "day". > >> > >> Yes, "ff#" are mapped to DCH_FF# like "mi" is mapped DCH_MI. > >> > >> "Day", "day" are not mapped to DCH_DAY because they determine letter case > >> in the > >> output, but "ff1" and "FF#" output contains only digits. > > > > Right, DCH_poz is also offset in DCH_keywords array. So, if array has > > an entry for "ff1" then enum should have a DCH_ff1 member in the same > > position. > > > > I guess my question is why we define DCH_ff# at all, when it's not > mapped in DCH_keywords? ISTM we could simply leave them out of all the > arrays, no?
I think we still need separate array entries for "FF1" and "ff1". At least, as long as we don't allow "fF1" and "Ff1". In order to get rid of DCH_ff#, I think we should decouple DCH_keywords from array indexes. > Of course, this is not specific to this patch, as it applies > to pre-existing items (like DCH_mi). Right, that should be a subject of separate patch. ------ Alexander Korotkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company