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.
* Make Query & NativeQuery implement the promise interface
* Fix test
* Use older node API for checking listener length
* Do not test for promises on node@v0.10.0
Fixes a case where you connect & immediatley disconnect and _sometimes_ your notification subscription starts the reader on the libpq instance after the libpq instance is disconnected. This segfaults the app.
This completes the port from the old native bindings to the new node-pg-native bindings!
Time to build in support for older versions of postgres & start the pull request process.
If you receive an error while running a query and in user's callback
they throw an exception it can disrupt the internal query queue
and prevent a client from ever cleaning up properly
If you throw an exception in a query callback the client will not pulse
its internal query queue and therefor will never process any
more queries or emit its own 'drain' event.
I don't find this to be an issue in production code since I restart
the process on exceptions, but it can break tests and cause things
to 'hang'. My crude benchmarks show no noticable impact in perf
from the try/catch/rethrow.
:q
1. Pass an error to an active query if the client is ended while a query is in progress.
2. actually emit 'end' event on the client when the stream ends
3. do not emit an error from native bindings if lasterror is null
For some reason a few years ago I thought it would be neat to use a shorthand version of prototype to save myself some keystrokes. That was a cosmetic mistake. It also breaks ctags.
Also, normalized some whitespace.
