On 10/02/12 08:50, Robert Haas wrote:
> On Fri, Feb 10, 2012 at 1:24 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> > Peter Eisentraut <pete...@gmx.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
