=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilm...@ilmari.org> writes:
> Tom Lane <t...@sss.pgh.pa.us> writes:
>>> We could do something hacky like matching case only when there's
>>> no longer any matching object names, but that might be too magic.
>> I experimented with that, and it actually doesn't seem as weird
>> as I feared. See if you like this ...
> That's a reasonable compromise, and the implementation is indeed less
> hacky than one might have feared. Although I think putting the
> `num_keywords` variable before `num_other` would read better.
After a few days of using that, I'm having second thoughts about it,
because it turns out to impede completion in common cases. For
example,
regression=# set transa<TAB><TAB>
TRANSACTION transaction_isolation
transaction_deferrable transaction_read_only
It won't fill in "ction" because of the case discrepancy between the
offered alternatives. Maybe this trumps the question of whether you
should be able to distinguish keywords from non-keywords in the menus.
If we case-folded the keywords as per your original proposal, it'd do
what I expect it to.
In previous releases, this worked as expected: "set transa<TAB>"
immediately completes "ction", and then tabbing produces this
menu:
transaction transaction_isolation
transaction_deferrable transaction_read_only
That probably explains why these keywords were lower-cased in
the previous code. However, I don't think we should blame
your suggestion to upcase them, because the same problem arises
in other completion contexts where we offer keywords. We should
solve it across-the-board not just for these specific queries.
regards, tom lane
