On Monday, January 24, 2022 6:36 PM, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote:
> The way your patch works now is that the case-insensitive behavior you
> are implementing only works if the client encoding is a single-byte
> encoding. This isn't what downcase_identifier() does;
> downcase_identifier() always works for ASCII characters. As it is, this
> patch is nearly useless, since very few people use single-byte client
> encodings anymore. Also, I think it would be highly confusing if the
> tab completion behavior depended on the client encoding in a significant
> way.
Thanks for your review. I misunderstood the logic of downcase_identifier().
Modified the code to support ASCII characters input.
> Also, as I had previously suspected, your patch treats the completion of
> enum labels in a case-insensitive way (since it all goes through
> _complete_from_query()), but enum labels are not case insensitive. You
> can observe this behavior using this test case:
>
> +check_completion("ALTER TYPE enum1 RENAME VALUE 'F\t\t", qr|foo|, "FIXME");
> +
> +clear_line();
Your suspect is correct. I didn't aware enum labels are case sensitive.
I've added this test to the tap tests.
> You should devise a principled way to communicate to
> _complete_from_query() whether it should do case-sensitive or
> -insensitive completion. We already have COMPLETE_WITH() and
> COMPLETE_WITH_CS() etc. to do this in other cases, so it should be
> straightforward to adapt a similar system.
I tried to add a flag(casesensitive) in the _complete_from_query().
Now the attached patch passed all the added tap tests.
Regards,
Tang