* Another attempt to fix pgbouncer error (1093.)
* Fixes for various pgbouncer problems.
* different approach with custom cursor.
* Fix rebase.
* Missed this.
* Fix completion refresher test.
* Black.
* Unused import.
* Changelog.
* Fix race condition in test.
* Switch from is_pgbouncer to more generic is_virtual_database, and duck-type it. Add very dumb unit test for virtual cursor.
* Remove debugger code.
The format_output chooses to output as a table or in the expanded
format on the basis of the length of the first line of the table
formatter (`len`). However, this first line contains a lot of ANSI
excape codes, so this comparison is wrong, and the expanded mode
is used either way. This patch strips these escape codes before the
comparison.
* Updated Vagrant file as it wasn't working.
* adding a space to kick the build process.
* removed packaging which wasn't really needed.
Co-authored-by: ERYoung11 <YoungEricR@JohnDeere.com>
* fixing test_config.py to work on windows
* Getting rid of odd characters in wrappager.py
* added a space to a comment to try to kick the github workflow.
Co-authored-by: Eric Young <YoungEricR@JohnDeere.com>
1. `class A(object)` can be written as `class A:`
2. replace `dict([…])` and `set([…])` with `{…}`
3. use f-strings or compact `.format`
4. use `yield from` instead of `yield` in a `for` loop
5. import `mock` from `unittest`
6. expect `OSError` instead of `IOError` or `select` error
7. use Python3 defaults for file reading or `super()`
8. remove redundant parenthesis (keep those in tuples though)
9. shorten set intersection instead of creating lists
10. backslashes in strings do not have to be escaped if prepended with `r`
These config properties got introduced in 41dd24e8 as a means to have
more granular control over the syntax highlighting. The problem is that
these cannot be in the default config file since `get_config()` always
reads both the default config file and the user specified one, and there
is no way to unset these variables in the user specified config file to
restore their default behavior. Even if there would be a way, it
wouldn't be intuitive at all to be required to unset some random
settings under the `[colors]` section just to be able to use the well
documented `syntax_style` setting.
Note that one *can* still set these three lines in their user config
file if they want to utilize them.
Resolves#1212