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`.
* Remove redundant tests
* Add client connectionString test
Add test to ensure { connectionString } is respected as an argument to the client constructor
* Add test for connection string property
Also fixed some legacy require statements.
* 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
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
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.
* Initial work on removing internal pool
* Port backwards-compabible properties
* Cleanup test execution & makefile cruft
* Attempt to fix flakey error test
* 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
When user provides a knex select statement with an undefined options in where clause it is not properly handled an give an ambiguous error message telling `Unhandled rejection TypeError: Cannot read property 'toString' of undefined.` This PR will helpful to users at it will tell them the exact problem.
There was some nasty global-ish variable reference updating happening when the native module 'initializes' after its require with `require('pg').native`
This fixes the issue by making sure both `require('pg')` and `require('pg').native` each initialize their own context in isolation and no weird global-ish references are used & subsequently stomped on.
I noticed that query cancellation was not working when connecting through pgbouncer,
even though it worked fine when directly connected. This is because we're appending an
extra null byte, and pgbouncer is strict about the packet length.
(per http://www.postgresql.org/docs/9.1/static/protocol-message-formats.html)
This removes the extraneous byte, which fixes cancellation against pgbouncer.
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
