Stephen Frost <sfrost@snowman.net> writes:
> There's a couple of other interesting corner cases, such as:
Yeah. I had been thinking of this as purely a performance issue, but
if we want to consider adjusting the visible behavior as well, that
makes it a completely different thing.
> select * from "spa<tab>
> Will return nothing, but:
> select * from spa<tab>
> Works just fine.
Of course this is because quote_ident() only quotes if necessary.
> Similar, if you have a table called "TEST", then:
> select * from "TE
> works, but:
> select * from TE
> (or any other combo w/o a quote)
> doesn't work.
And that's because we're comparing to quote_ident() output, which
will have quotes in this case.
I wonder whether it would work to do something like this: if the word to
be tab-completed starts with a quote, compare to quote_ident output;
otherwise, compare to relname (or other name column) directly.
We'd still emit quote_ident output, which means that if you did
select * from TE<TAB>
it would change that to
select * from "TEST
(assuming you had say TEST1 and TEST2 so it couldn't complete further).
That seems like it would be a step forward in usability. I'm not sure
that this covers all the corner cases usability-wise though.
From a performance point of view, this would be fast for the unquoted
case (if combined with Stephen's idea to use LIKE). It'd still be slow
for quoted input though.
But then take another step: if the word-so-far has a leading quote and
no embedded quotes, we can clearly strip the leading quote and compare
the rest directly to the name column. So that can be fast. The only
cases that need be slow are names with embedded quotes, which surely
isn't a case that too many people care about.
In short, I think we might be able to make this fast, and more usable,
just with hacking on psql's query generation rules. There's no need for
server-side changes.
regards, tom lane
