Re: psql tab completion for SELECT

On Fri, Feb 10, 2012 at 11:01 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Fri, Feb 10, 2012 at 10:20 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> I'm not against tab-completing functions, if people think that's
>>> useful.  I am against tab-completing them in 1% of use-cases, which is
>>> what this patch accomplishes.  The fact that it's short doesn't make it
>>> good.
>
>> Our tab completion is in general very incomplete; we have made a
>> practice of cherry-picking the most commonly encountered cases and
>> handling only those.  Whether or not that is a good policy is a
>> philosophical question, but there is no reason to hold this particular
>> patch to a higher standard than the quality of our tab completion code
>> in general.
>
> Well, if you want a patch with low standards, what about tab-completing
> function names anywhere that we do not see context suggesting something
> else?  I really think that doing it only immediately after SELECT is
> going to prove far more of an annoyance than a help, because once you
> get used to relying on it you are going to wish it worked elsewhere.

I think that without a bit more contextual information that's likely
to lead to some odd results. Unimplemented completions will lead to
bizarre things happening.

One thing that's been bugging me for a while is that the tab
completion code all works by looking backward up to n words. What we
really want to know is what kind of statement we're in and where we
are in it. Absent other information, if we're in the target list of a
SELECT statement (nested arbitrarily) that behavior is reasonable. If
we're someplace in a GRANT statement, or someplace in a CREATE
STATEMENT where, say, a column name is expected, it's really not.

Unfortunately, making the tab completion something other than
incredibly stupid is likely to be an insane amount of work.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company