On Fri, Feb 10, 2012 at 11:01 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Feb 10, 2012 at 10:20 AM, Tom Lane <tgl@sss.pgh.pa.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