Re: psql tab completion for SELECT - Mailing list pgsql-hackers

From Robert Haas
Subject Re: psql tab completion for SELECT
Date
Msg-id CA+TgmobjCahHxkLZ=U=hB3hLG2ZoShX0E86EGxB70B3DV_5EUA@mail.gmail.com
Whole thread Raw
In response to Re: psql tab completion for SELECT  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Feb 10, 2012 at 11:22 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Feb 10, 2012 at 11:01 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> 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 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.
>
> True.  I was first thinking of doing this only if we know we're in
> a DML query, ie *first* word on the line is
> WITH/SELECT/INSERT/UPDATE/DELETE.  However, in the current
> implementation that is not terribly workable because we are only looking
> at the current line of text, not the whole input buffer; so making such
> a restriction would disable completion after the first line of a multi-
> line command.
>
>> 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.
>
> Yup.  At the very least it would be good if it had access to the entire
> current command, so that we could sanity-check on the basis of the first
> word.

Agreed.

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: psql tab completion for SELECT
Next
From: Jean-Baptiste Quenot
Date:
Subject: Fix PL/Python metadata when there is no result