This adds deprecations in preparation for `pg@7.0`
- deprecate using event emitters on automatically created results from client.query.
- deprecate query.promise() - it should never have been a public method and it's not documented. I need to do better about using _ prefix on private methods in the future.
- deprecate singleton pool on the `pg` object. `pg.connect`, `pg.end`, and `pg.cancel`.
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.
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.
When a __prepared statement__ has no body in the query the backend responds with an `emptyQuery` message but never with a `commandComplete` or `errorResponse` message. The client was hanging forever waiting for one of the other two expected messages. The server was hanging forever waiting for the client to respond with a `sync` message. This change has the client send the required `sync` on receipt of an `emptyQuery` message when the query is a prepared statement. Fixes#822
The code is failing with pg-copy-streams. The pg-copy-streams creates a query object but it doesn't have any _result. Make the type parser an optional only when _result object available on query then only set the type parser.
a fix was provided in 5079c1e0c41f431ac2e02c40ebd875d8fbb34004;
test is modeled on query-error-handling-tests.js;
test both kill query and disconnection on prepared statement execution;
make connection error string message consistent between native and non-native;
disable test server-side kill for native as it hangs;
sync can cause error to be emitted so we catch that;
we also move _ending state before _send is called.
Before the change, it would crash with a very unhelpful error message:
[project path]/node_modules/pg/lib/query.js:92
connection.sync();
^
TypeError: Cannot call method 'sync' of undefined
at Query.handleError ([project path]/node_modules/pg/lib/query.js:92:16)
at Client.connect ([project path]/node_modules/pg/lib/client.js:178:24)
at g (events.js:185:14)
at EventEmitter.emit (events.js:85:17)
at Socket.<anonymous> ([project path]/node_modules/pg/lib/connection.js:60:10)
at Socket.EventEmitter.emit (events.js:85:17)
at TCP.onread (net.js:424:51)
After the change, it reports a much more helpful
error running query [Error: Stream unexpectedly ended during query execution]
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
