Re: psql tab completion for SELECT
От | Robert Haas |
---|---|
Тема | Re: psql tab completion for SELECT |
Дата | |
Msg-id | CA+TgmoZ=aQDD2jwMB9FULxQUFMR7guCdd2RAh-ZRv6g=p2Ng7g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: psql tab completion for SELECT (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: psql tab completion for SELECT
|
Список | pgsql-hackers |
On Fri, Feb 10, 2012 at 10:20 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Fri, Feb 10, 2012 at 1:24 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> That seems pretty nearly entirely bogus. What is the argument for >>> supposing that the word right after SELECT is a function name? > >> It isn't necessarily, but it might be. It'd certainly be nice to type: >> SELECT pg_si<TAB> >> and get: >> SELECT pg_size_pretty( > > Yeah, and then you'll type > > SELECT pg_size_pretty(pg_dat<TAB> > > and get nothing, and curse the authors of such a misbegotten incomplete > concept that leads your fingers to rely on something that doesn't work > where it should. > > 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: