> 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 <robertmh...@gmail.com> wrote: > > On Fri, Jul 9, 2021 at 10:44 AM Tomas Vondra > <tomas.von...@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
