On Monday, January 24, 2022 6:36 PM, Peter Eisentraut <[email protected]> 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
v13-0001-Support-tab-completion-with-a-query-result-for-u.patch
Description: v13-0001-Support-tab-completion-with-a-query-result-for-u.patch
