* Going red: using a config object creates two pools when missing some params
It should only create a pool in a consistent way, even if some params
are not provided in the first place.
* Delay the pool name generation to make it consistent between calls
* Don't fallback to empty object as config is already defined
* Fix escaping of libpq connection string properties
Fix handlings of libpq connection properties to properly escape single
quotes and backslashes. Previously the values were surrounded in single
quotes which handled whitespace within the property value, but internal
single quotes and backslashes would cause invalid connection strings to
be generated.
* Update expected output in test to be quoted
Update the expect host output in the connection parameter test
to expect it to be surrounded by single quotes.
* Add test for configs with quotes and backslashes
* Improve Readme.md for not so advanced users
1. Add brief description about the 3 possible ways of executing queries: passing the query to a pool, borrowing a client from a pool or obtaining an exclusive client. Give examples for the 3 of them.
2. Use the examples to teach how to reuse a pool in all of your project. This should be helpful for not so advanced users and prevents mistakes.
3. Open a troubleshooting section.
* Shrink Troubleshooting and Point to Examples
1. Troubleshooting/FAQ section will only contain a reference to the wiki FAQ. I've already moved the content to the wiki.
2. At the end of "Pooling example" point to the wiki example page. Also indicate that there they can find how to use node-postgres with promises and async/await. I've already created that content in the wiki.
On Windows, after a connect attempt has failed, an error event with
ECONNRESET is emitted after the real connect error is propagated to the
connect callback, because the connection is not in ending state
(connection._ending) where ECONNRESET is ignored. This change ends the
connection when connect has failed.
This fixes#746.
* Avoid infinite loop on malformed message
If handling of such messages is deemed unimportant, `indexOf` is still faster (~40%) and cleaner than a manual loop.
Addresses #1048 to an extent.
* Use indexOf fallback for Node ≤0.12
They were disabled by 4cdd7a116b without comment; it seems that this might have been unintentional?
In any case, they should probably be enabled, updated, or removed.
* Use container-based CI
* Remove unnecessary CI configuration
* Use Node 6/PostgreSQL 9.6 as default test
… rather than testing 0.10 twice with unspecified PostgreSQL.
* Use `precise` for PostgreSQL 9.1
According to https://docs.travis-ci.com/user/database-setup/, 9.1 isn’t supported on trusty.
* Fix Node 0.10 and 0.12 CI builds
These binaries appear to have been built using g++ with flags that clang doesn’t support. Or something.
Setting PostgreSQL 9.5 as the main version to test against.
NOTE: The following settings are required for 9.5 to work:
```
sudo: required
dist: trusty
```
A long standing bug was the pure JS client didn't accept or call a callback on `client.end`. This is inconsistent with both the documentation & general node patterns.
This fixes the issue & adds a test. The issue did not exist in the native version of the client.
The promise adapter I had implemented wasn't spec compliant: it didn't accept both `onSuccess` and `onFailure` in the call to `query#then`. This subtly broke yield & async/await because they both rely on `onError` being passed into `Promise#then`. The pool was also not returning the promise after a client was acquired, which broke awaiting on `pool.connect` - this is also fixed now.
