On Sun, Feb 19, 2012 at 12:10 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
> I found so this extremely simple patch should be useful.
> It helps for pattern SELECT fx();
> There was thread about it.
I signed up to be reviewer for this patch, and finally got around to
taking a look. This thread, and the thread about Peter's earlier patch
along the same lines have gotten a bit muddled, so allow me some recap
for my own sanity.
The first point to be addressed, is that Pavel's patch is basically a
subset of Peter's earlier patch. Pavel's patch autocompletes
with possible function names. Peter's patch autocompletes both
possible column names and possible function names. So, which version,
if any, would we want? Both Tom and depesz have asked for column
names to be autocompleted if we're going to go down this road, and I
personally would find completion of column names handy. Others 
have asked for function names to be (also?) autocompleted here, so it
seems reasonable that we'd want to include both.
I counted two general objections to Peter's patch in these threads, namely:
1.) Complaints about the tab-completion not covering all cases,
possibly leading to user frustration at our inconsistency.  
2.) Concerns that the tab-completion wouldn't be useful given how
many results we'd have from system columns and functions 
I do agree these are two legitimate concerns. However, for #1, our
tab-completion is and has always been incomplete. I take the basic
goal of the tab-completion machinery to be "offer a suggestion when
we're pretty sure we know what the user wants, otherwise stay quiet".
There are all sorts of places where our reliance on inspecting back
only a few words into the current line and not having a true command
parser prevents us from being able to make tab-completion guesses, but
that's been accepted so far, and I don't think it's fair to raise the
bar for this patch.
Re: concern #2, Tom complained about there being a bunch of possible
column and function completions in the regression test database. That
may be true, but if you look at this slightly-modified version of the
query Peter's patch proposes:
SELECT substring(name, 1, 3) AS sub, COUNT(*)
SELECT attname FROM pg_attribute WHERE NOT attisdropped
SELECT proname || '(' FROM pg_proc p WHERE
pg_catalog.pg_function_is_visible(p.oid)) t (name)
GROUP BY sub ORDER BY COUNT(*) DESC;
I count only 384 distinct 3-length prefixes in an empty database,
thanks to many built-in columns and functions sharing the same prefix
(e.g. "int" or "pg_"). Obviously, there is plenty of room left for
3-length prefixes, out of the 27^3 or more possibilities. In some
casual mucking around in my own databases, I found the
column-completion rather useful, and typing 3 characters of a
column-name to be sufficient to give matches which were at least
non-builtin attributes, and often a single unique match.
There were some ideas down-thread about how we might filter out some
of the noise in these completions, which would be interesting. I'd be
happy with the patch as-is though, modulo the attisdropped and
pg_function_is_visible() tweaks to the query.
In response to
pgsql-hackers by date
|Next:||From: Josh Kupershmidt||Date: 2012-06-19 04:16:57|
|Subject: Re: patch: autocomplete for functions|
|Previous:||From: Robert Haas||Date: 2012-06-19 04:01:17|
|Subject: Re: pgsql_fdw in contrib|