Having typed an alias name in an `ORDER BY` or (`SELECT`) `DISTINCT`
clause, the alias was not taken account of, and the completion simply
listed all columns. This change fixes that, and makes the autocompletion
behave the same as in `SELECT` and `WHERE` clauses.
A bunch of cosmetic changes to be more compliant with PEP80 and pylint.
And I added a pylintrc so that we can ignore some rules that just add
too much clutter.
This introduces functionality for running the same test case for
different completer settings. This should improve code-path coverage.
I've set up all the old tests to run with all configs that should have
identical output.
Consider this script
```
CREATE FUNCTION foo() returns text LANGUAGE SQL AS $func$
SELECT 1 FROM Bar;
SELECT <cursor> FROM Baz;
$func$;
```
The change here is that `SELECT <cursor> FROM Baz;` will be seen as the
current statement, instead of the whole function definition.
This means we'll no longer get column suggestions from `Bar`.
And schema-qualifying them, of course, so that for `SELECT * FROM bar`
we might suggest `buildings.barns` and for `select dopi` we might
suggest `maintenance.delete_old_personal_info()`, for example.
Controlled by a config setting, `search_path_filter`, in case anyone
prefers the old behaviour.
E.g. for table `Foo` with columns `FooBar` and `Fabulous`, inputting
`SELECT * FROM Foo F WHERE F.fb` will suggest `FooBar` as the #1 choice.
Likewise, given the functions `baz_baz()` and `baab()`, inputting
`SELECT bb` will have `baz_baz()` as the first option.
The idea is that if you have e.g. a table called `FooBar`, where we'd
use the initialism `FB` as an alias (suggesting `FooBar FB`),
inputting e.g. `SELECT * FROM FB` should suggest `FooBar FB` (or
`FooBar` if aliasing is disabled). Ditto for functions, views and joins.
The solution is that we send `FB` as a `synonym` to `find_matches`,
which results in the `FooBar` suggestion rising to the top (above e.g.
`FabulousTable`).
... i.e. suggesting foo.fooid instead of just fooid
Controlled using a config-file setting:
**qualify_columns**: always/never/**if_more_than_one_table**.
To enable the proper sorting of qualified column suggestions, we
introduce the concept of synonyms for suggestions
(in `pgcompleter.find_matches`). They way synonyms work is that a
number of synonyms may be provided for a suggestion sent to
`find_matches`. If synonyms are provided, sorting is based on how
well the best synonym matches the input, instead of only comparing
the input to the suggestion text.
In this case, the unqualified name acts as a synonym.
I have a couple of other ideas of use cases where we can use synonyms
to get better completions with less typing for the user, which I intend
to explore later.
Python 3 forbids comparisons between different types: use a tuple
containing a single 0 (zero) as the priority for path matches so that it
can be compared with those generated by the workhorse method find_matches().
