On Sun, Feb 19, 2012 at 12:10 PM, Pavel Stehule <pavel.steh...@gmail.com> wrote: > Hello > > I found so this extremely simple patch should be useful. > > It helps for pattern SELECT fx(); > > There was thread about it.
Hi Pavel, 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 SELECT <TAB> 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(*) FROM ( SELECT attname FROM pg_attribute WHERE NOT attisdropped UNION 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. Josh  http://archives.postgresql.org/message-id/1328820579.11241.4.camel%40vanquo.pezone.net  http://archives.postgresql.org/message-id/7745.1328855069%40sss.pgh.pa.us  http://www.depesz.com/2011/07/08/wish-list-for-psql/  http://archives.postgresql.org/message-id/13612.1328887227%40sss.pgh.pa.us  http://archives.postgresql.org/message-id/CA%2BTgmoY7wRGgBbFhKwfASqrNOPwZwCjfm1AhL82769Xx-SyduA%40mail.gmail.com  http://archives.postgresql.org/message-id/20120210140637.GB19783%40ldn-qws-004.delacy.com  http://archives.postgresql.org/message-id/9966.1331920074%40sss.pgh.pa.us -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers