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.
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`.
... 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.
This commit makes it so that given `INSERT INTO foo(<cursor1>) SELECT <cursor2> FROM bar;`, we suggest `bar` columns for `<cursor2>` and `foo` columns for `<cursor1>`. Previous behaviour is sugggesting columns from both tables in both cases.
If config.main.generate_aliases is True, for `SELECT * FROM `, we suggest `FooBar FB` and `foo_bar fb` instead of `FooBar` and `foo_bar`, respectively.
To be able to add a test, I had to add support for testing with different settings, which meant I could also add tests for casing.
There are two non-obvious changes that I can think of:
1. The lexical sorting of matches is modified so as to sort spaces and underscores before letters and to sort case-insensitively. This is so that e.g `Foob F` comes before 'FooBar FB' when `foob` is input.
2. We now suggest `some_func()` instead of `some_func` (because suggesting `some_func sf` didn't make any sense).
If we have the input `SELECT * FROM Foo JOIN `, we now suggest `Foo Foo2 ON Foo2.ParentID = Foo.ID` (given the appropriate casing file and FK).
There were also some problems with quoted tables and with the casing of table aliases, which are now fixed.
I also made a few cosmetic changes to get_join_matches (pgcompleter.py) just to make it a bit easier to work with.
This is based on my previous work on suggesting join conditions, but here instead we suggest the whole join. What we do is simply check all the tables in the statement for FK relationships and then suggest joins based on those. I think this will not only save key presses, but also be rather useful when exploring an unfamiliar (part of a) database.
There's one non-obvious change in this commit (that I can think of): When calling **sqlcompletion.text_before_cursor**, the **text_before_cursor** argument now no longer includes **word_before_cursor**. This is because for 'SELECT * FROM foo JOIN bar<cursor>', we would otherwise consider the table **bar** already included in the statement and thus suggest e.g. 'baz on baz.barid = bar.barid'.
The user types 'SELECT * FROM parenttable p JOIN childtable c on '. We then suggest ['c.parenttableid = p.parenttableid', 'c.createdby = p.createdby', ...] as completions.
The suggestions are FK matches first, then name matches for int columns, then name matches for other columns, sorted by proximity from the cursor to the other table.
Some changes:
For "JOIN Foo USING(<cursor>)", now only columns present in Foo are suggested.
For all suggestions after 'ON', now only the tables before the cursor are considered.
meta[reltype]][relname] goes from being a list of columns to being an OrderedDict {column_name:ColumnMetadata}, where the ColumnMetaData contains the column's name, data type and a list of FKs involving the column. This entails modification of a number of functions dealing with columns.
Change from filtering out all non-set-returning functions to only filteirng out windowing functions and aggregate functions.
Non-set-returning functions are legal in the FROM clause and can be quite useful.
Previously, this worked correctly, suggesting columns etc. from `a`
`SELECT * FROM abc a JOIN def d ON a.`
But this suggested only keywords:
`SELECT * FROM abc a JOIN def d ON a.id = d.id AND a.`
sqlparse groups tokens belonging to the where clause into a single Where token (a subclass of TokenList). In order to handle cases beyond the simplest `SELECT * FROM foo WHERE`, we need to look "inside" of this token list.
because sqlparse parses things like 'inner join' as a single token, simply checking if token value
matches 'join' fails on further specified join types
