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:01:54 |
Message-ID: | 14225.1328889714@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2012-02-10 16:08:54 | Re: psql tab completion for SELECT |
Previous Message | Robert Haas | 2012-02-10 15:56:23 | Re: Patch: fix pg_dump for inherited defaults & not-null flags |