| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, hubert depesz lubaczewski <depesz(at)depesz(dot)com> |
| Subject: | Re: psql tab completion for SELECT |
| Date: | 2012-02-10 16:22:48 |
| Message-ID: | 14581.1328890968@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Feb 10, 2012 at 11:01 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2012-02-10 16:23:50 | Re: psql tab completion for SELECT |
| Previous Message | Tom Lane | 2012-02-10 16:10:48 | Upcoming PG back-branch releases, end of this month |