Sehrope Sarkuni

> * I think the docs should explicitly mention that connection errors (and query errors, from my findings) should be passed to `client.release`. We can [send a PR](https://github.com/brianc/node-postgres-docs) for that...

> @sehrope I found that clients couldn’t be reused even after a UNIQUE key violation, but perhaps that was just something wrong with my setup. I’m afraid I can’t confirm...

@vitaly-t wrote: > Here's what troubles me... this documentation implies that the client is supposed to be able to identify a dropped connection from all other types of errors, if...

> If we are not clever enough, we may dispense with alive connection while inside a transaction by mistake. If you're the one handling transaction management then you know if...

@vitaly-t Okay that makes sense as a workaround but only because not bubbling up the connection error was a bug. Assuming that's fixed you shouldn't have to do anything like...

The default would be to hang indefinitely as that's the default behavior for TCP sockets without explicit timeouts or keep alives. You can set keep alive options on the client...

@vitaly-t This isn't about the callback vs Promise return type of the query. This is in regards to the data type of query parameters passed in the `params` array. The...

If you're going to refactor the channel binding options being passed into the ScramAuthenticator then do that in its own commit. Ideally in its own PR so that we see...

The original commit in this PR had the options changes but that was done in #3667 so now only the test changes remain.

Does this always get called with a fully qualified name? If so that seems the correct thing to do here. Otherwise how do you deal with oddball edge cases like...