On Tue, Jun 17, 2014 at 5:18 PM, Robert Haas <robertmh...@gmail.com> wrote: > What bash does is annoying and stupid, and any time I find a system > with that obnoxious behavior enabled I immediately disable it, so I > don't consider that a good precedent for anything.
I happen to totally agree with you here. Bash sometimes does awful things with its completion. >> Another issue is whether to print only those having exactly the minimum >> observed Levenshtein distance, or to print everything less than some >> cutoff. The former approach seems to me to be placing a great deal of >> faith in something that's only a heuristic. > > Well, we've got lots of heuristics. Many of them serve us quite well. > I might do something like this: > > (1) Set the maximum levenshtein distance to half the length of the > string, rounded down, but not more than 3. > (2) If there are more than 2 matches, reduce the maximum distance by 1 > and repeat this step. > (3) If there are no remaining matches, print no hint; else print the 1 > or 2 matching items. I could do that. I can prepare a revision if others feel that's acceptable. My only concern with this is that a more sophisticated scheme implies more clutter in the parser, although it should not imply wasted cycles. What I particularly wanted to avoid in our choice of completion scheme is doing nothing because there is an ambiguity about what is best, which Tom suggested. In practice, that ambiguity will frequently be something that our users will not care about, and not really see as an ambiguity, as in my "o.orderid or ol.orderid?" example. However, if there are 3 equally distant Vars, and not just 2, that's very probably because none are useful, and so we really ought to show nothing. This seems most sensible. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
