> This patch is still in the current CommitFest, so I decided to review
> it. I see that DCH_keywords[] includes upper and lower-case entries
> for everything except the three cases corrected by this patch, where
> it includes upper-case entries but not the corresponding lower-case
> entries. It seems to make sense to make these three cases consistent
> with everything else.
>
> It took me a while to understand how DCH_keywords[] and DCH_index[]
> actually work, and I think it's a pretty confusing design, but what
> the patch does seems to be consistent with that, so it appears correct
> to me.
>
> Therefore, I have committed it.
Thank you so much.
Thanks & Regards,
Nitin Jadhav
On Tue, Mar 15, 2022 at 2:22 AM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Fri, Jul 9, 2021 at 10:44 AM Tomas Vondra
> <tomas.vondra@enterprisedb.com> wrote:
> > Yeah, does not seem to be worth it, as there seem to be no actual
> > reports of issues in the field.
> >
> > FWIW there seem to be quite a bit of other to_char differences compared
> > to Oracle (judging by docs and playing with sqlfiddle). But the patch
> > seems fine / simple enough and non-problematic, so perhaps let's just
> > get it committed?
>
> This patch is still in the current CommitFest, so I decided to review
> it. I see that DCH_keywords[] includes upper and lower-case entries
> for everything except the three cases corrected by this patch, where
> it includes upper-case entries but not the corresponding lower-case
> entries. It seems to make sense to make these three cases consistent
> with everything else.
>
> It took me a while to understand how DCH_keywords[] and DCH_index[]
> actually work, and I think it's a pretty confusing design, but what
> the patch does seems to be consistent with that, so it appears correct
> to me.
>
> Therefore, I have committed it.
>
> --
> Robert Haas
> EDB: http://www.enterprisedb.com
