Thanks for the thorough report. I can see this is a problem. Let me see if this is best solved on the front- or back-end.

OK. I wanted to figure out where this issue came from. Note that we use the buffer npm package in our driver to shim Buffer for platforms that aren't Node.

We call prepareValues on query parameters for HTTP queries: https://github.com/brianc/node-postgres/blob/95d7e620ef8b51743b4cbca05dd3c3ce858ecea7/packages/pg/lib/utils.js#L47

This leaves Buffer objects well alone, and it turns typed arrays (such as Uint8Array) into Buffer objects too (using the test ArrayBuffer.isView).

As an aside, ArrayBuffer objects get no special handling: they're identified only as objects and get inserted as the 2 bytes{} even over TCP/WebSockets. It might be nice to fix that, but my key priority is node-postgres compatibility, so I'm going to park this idea for now.

When querying over WebSockets, the prepared Buffer objects are then handled specially in the Postgres protocol/serializer code, so everything works out: https://github.com/brianc/node-postgres/blob/95d7e620ef8b51743b4cbca05dd3c3ce858ecea7/packages/pg-protocol/src/serializer.ts#L123.

But over HTTP the Buffer objects just get passed to JSON.stringify, which uses toJSON() to turn them into an object like { type: 'Buffer', data: [ 0 ] }.

So: I think we do need to handle these objects specially for HTTP on the client side. We can't do this nicely on the back-end, since it will be hard at that point to distinguish the stringified data from any other string.

What you've done in #119 looks pretty sensible on this score, so many thanks.

I've also investigated how the buffer package handles toString('hex'), and it's fine but not brilliant. I'm sounding them out about making it 2 – 4x quicker: feross/buffer#364