Re: Support tab completion for upper character inputs in psql - Mailing list pgsql-hackers

Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> The rest of the patch seems ok in principle, since AFAICT enums are the 
> only query result in tab-complete.c that are not identifiers and thus 
> subject to case issues.

I spent some time looking at this patch.  I'm not very happy with it,
for two reasons:

1. The downcasing logic in the patch bears very little resemblance
to the backend's actual downcasing logic, which can be found in
src/backend/parser/scansup.c's downcase_identifier().  Notably,
the patch's restriction to only convert all-ASCII strings seems
indefensible, because that's not how things really work.  I fear
we can't always exactly duplicate the backend's behavior, because
it's dependent on the server's locale and encoding; but I think
we should at least get it right in the common case where psql is
using the same locale and encoding as the server.

2. I don't think there's been much thought about the larger picture
of what is to be accomplished.  Right now, we successfully
tab-complete inputs that are prefixes of the canonical spelling (per
quote_identifier) of the object's name, and don't try at all for
non-canonical spellings.  I'm on board with trying to allow some of
the latter but I'm not sure that this patch represents much forward
progress.  To be definite about it, suppose we have a DB containing
just two tables whose names start with "m", say mytab and mixedTab.
Then:

(a) m<TAB> immediately completes mytab, ignoring mixedTab

(b) "m<TAB> immediately completes "mixedTab", ignoring mytab

(c) "my<TAB> fails to find anything

(d) mi<TAB> fails to find anything

(e) M<TAB> fails to find anything

This patch proposes to improve case (e), but to my taste cases (a)
through (c) are much bigger problems.  It'd be nice if (d) worked too
--- that'd require injecting a double-quote where the user had not
typed one, but we already do the equivalent thing with single-quotes
for file names, so why not?  (Although after fighting with readline
yesterday to try to get it to handle single-quoted enum labels sanely,
I'm not 100% sure if (d) is possible.)

Also, even for case (e), what we have with this patch is that it
immediately completes mytab, ignoring mixedTab.  Is that what we want?
Another example is that miX<TAB> fails to find anything, which seems
like a POLA violation given that mY<TAB> completes to mytab.

I'm not certain how many of these alternatives can be supported
without introducing ambiguity that wasn't there before (which'd
manifest as failing to complete in cases where the existing code
chooses an alternative just fine).  But I really don't like the
existing behavior for (b) and (c) --- I should be able to spell
a name with double quotes if I want, without losing completion
support.

BTW, another thing that maybe we should think about is how this
interacts with the pattern matching capability in \d and friends.
If people can tab-complete non-canonical spellings, they might
expect the same spellings to work in \d.  I don't say that this
patch has to fix that, but we might want to look and be sure we're
not painting ourselves into a corner (especially since I see
that we already perform tab-completion in that context).

            regards, tom lane