* Require latest pg-pool ^2.0.7
to limit variability of next pg’s installations.
* Ignore EPIPE when writing termination message
I don’t know why this wasn’t necessary for tests to pass before…
* Fix disconnection tests for pg-pool 2.0.7
In pg-pool 2.0.7, checked-out clients became responsible for their own 'error' events.
brianc/node-pg-pool#123
* Bump version of pg-cursor
This includes fixes in pg-cursor@2.0.1. I've relaxed semver a touch so I don't have to release a new version here just for patch changes to pg-cursor.
* Pass options to pg-cursor
fixes#55
When code was added to use a random named portal instead of the empty portal to support redshift we didn't update the close messages approprately. This could result in postgres keeping locks on tables for modification if streaming and table modification was both done within a transaction. This update fixes the issue by always issuing a close command on the named portal when query is finished.
fixes#56
* Upgrade dependencies
- There was a security vuln with mocha, so upgraded mocha.
- Upgraded versions of node we're going to check in travis
- Switched to yarn from npm
- Removed --no-exit as that's standard mocha behavior now
* Enable postgres on newer version of travis
There are no tests covering cursor.end(). It's also a weird method to have on the cursor as it terminates the connection to postgres internally. I don't recall why I added this method in the first place but its not correct to close a connection to postgres by calling .end on a cursor...seems like a pretty big footgun. If you have a pooled client and you call `cursor.end` it'll close the client internally and likely confuse the pool. Plus it's just weird to be able to close a connection by calling .end on a query or cursor. So...I'm deprecating that method.
The throwOnRelease() function does not appear to be exposed anywhere,
and it does not appear to make any sense to have it as a standalone func,
as it ovecomplicates things and makes function call as non-returning. Inlined it.
* feat: Add dynamic retrieval for client password
Adds option to specify a function for a client password. When the client
is connected, if the value of password is a function then it is invoked
to get the password to use for that connection.
The function must return either a string or a Promise that resolves to
a string. If the function throws or rejects with an error then it will
be bubbled up to the client.
* test: Add testAsync() helper to Suite
Add testAsync() helper function to Suite to simplify running tests that
return a Promise. The test action is executed and if a syncronous error
is thrown then it is immediately considered failed. If the Promise resolves
successfully then the test is considered successful. If the Promise
rejects with an Error then the test is considered failed.
* test: Add tests for dynamic password
* test: Simplify testAsync error handling
* fix: Clean up dynamic password error handling and misc style
* test: Remove extra semicolons
* test: Change testAsync(...) calls to use arrow functions
* fix: Wrap self.password() invocation in an arrow function
* test: Add a comment to testAsync(...)
* Prevent double release with callback
When using the callback instead of client.release, double releasing
a client was possible causing clients to be re-added multiple times.
* Remove idleListener when client is in-use
When a client is in-use, the error handling should be done by the
consumer and not by the pool itself as this otherwise might cause
errors to be handled multiple times.
* Handle verify failures
* Fix deepEqual compare
In node 12 assert.deepEqual against a buffer & array no longer passes if the values are the same. This makes sense. Updated the test to not use deepEqual in this case.