Re: psql tab completion for SELECT

On 10/02/12 08:50, Robert Haas wrote:
> On Fri, Feb 10, 2012 at 1:24 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> >> That seems pretty useful, and it's more or less a one-line change, as in
> >> the attached patch.
> >
> > That seems pretty nearly entirely bogus.  What is the argument for
> > supposing that the word right after SELECT is a function name?  I would
> > think it would be a column name (from who-knows-what table) much more
> > often.
>
> 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(
>

Well the important problem in completion is how the dictionary of
possible terms is determined and how much context info is used to
reduce / enhance that dictionary.

case 1:

select x<TAB>

case 2:

select x<TAB> from bar

Possible dictionaries in case 1:

1.1 complete nothing
1.2 complete assuming the union of all columns from all tables
in the search_path as the dictionary.
1.3 complete assuming the union of all function names in the
search_path as the dictionary
1.4 complete assuming 1.2 and 1.3

Possible dictionaries in case 2:

2.1 treat it like case 1
2.2 complete assuming the union of all columns from bar
in the search_path as the dictionary
2.3 2.2 + 1.3

Now these are heuristics and the decision becomes a question
of usefulness vs amount of time it costs to implement and
possibly how expensive computing the dictionary is.

I personally would like 1.3 in case 1 and 2.3 in case 2,
because I expect 1.2 to be to show too many possible
completions to be useful. But even 1.3 in both cases wouldn't
be that bad.

Cheers,

Bene