On Fri, Feb 10, 2012 at 11:22 AM, Tom Lane <[email protected]> wrote: > Robert Haas <[email protected]> writes: >> On Fri, Feb 10, 2012 at 11:01 AM, Tom Lane <[email protected]> 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 -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
