* Revert "When connection fail, emit the error. (#28)"
This reverts commit 6a7edabc22e36db7386c97ee93f08f957364f37d.
The callback passed to `Pool.prototype.connect` should be responsible for handling connection errors. The `error` event is documented to be:
> Emitted whenever an idle client in the pool encounters an error.
This isn’t the case of an idle client in the pool; it never makes it into the pool.
It also breaks tests on pg’s master because of nonspecific dependencies.
* Don’t create promises when callbacks are provided
It’s incorrect to do so. One consequence is that a rejected promise will be unhandled, which is currently annoying, but also dangerous in the future:
> DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
The way callbacks are used currently also causes #24 (hiding of errors thrown synchronously from the callback). One fix for that would be to call them asynchronously from inside the `new Promise()` executor:
process.nextTick(cb, error);
I don’t think it’s worth implementing, though, since it would still be backwards-incompatible – just less obvious about it.
Also fixes a bug where the `Pool.prototype.connect` callback would be called twice if there was an error.
* Use Node-0.10-compatible `process.nextTick`
* When connection fail, emit the error.
If client connect failed, emit the connection error rather than swallowing it.
* Add test for connection error.
* Pool.query calls cb if connect() fails
Old behavior was that if connect called back with an error, the promise would get rejected but the cb function would never get called.
* Test that Pool.query passes connection errors to callback
* Fixes to standardjs compliance
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.
* fail: "connect" event only on success
Double callback invocation will also cause this to fail.
* avoid double callback: _create
If `client.connect` returns an error, then the callback for `Pool#_create` is only invoked once. Also the `connect` event is only emitted on a successful connection, the client is otherwise rather useless.
* legacy compat; don't use Object.assign
* legacy compat; events.EventEmitter
* Support function-like construction
Remove the necessity of using `new` in front of the `Pool`, i.e. allow it to be used as a regular function. This is following https://github.com/brianc/node-postgres/issues/1077
* add Pool factory test
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.
