On Sat, Jan 5, 2019 at 5:21 PM Tomas Vondra
<tomas.vondra@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.gluhov@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
