Reliably distinguishing between pool and client objects (both native and pure-JS)?

[jawj]

I'm quite stuck. I develop a TypeScript/Postgres library called Zapatos, and I have a pull request for a nice feature that lets users pass either a Pool or a connected Client to a transaction helper function (which, until now, has accepted only a Pool).

Obviously this relies on being able to distinguish the two cases, but I'm finding this impossible. In my testing, both x instanceof pg.Client and x instanceof pg.Pool always return false, regardless of which of the two things x actually is. (It may be relevant that, using the node debugger, x.constructor is reported as [Function] instead of the expected [class BoundPool extends Pool] or [class Client extends event.Emitter], but I haven't been able to work out why this is the case; x.constructor.name gives "BoundPool" or "Client" as I'd expect).

In addition, I'd like to be able to accept either pure JS or pg-native pool and client objects, and I'm not sure this instanceof test would ever work for pg-native ones?

I've toyed with the idea of checking for a connection property: this is undefined on pools but not on clients. But this also seems to fail with pg-native objects, where it's undefined on both pools and clients.

Any suggestions? I appreciate that a minimal test case would be useful here, but when I put together a test case everything works OK (and I can't currently figure out where the difference is coming from).

[jawj]

Update: for now, I'm testing (with instanceof) against pg.Pool, pg.Client, pg.native.Pool, and pg.native.Client. If all of those return false, then I resort to distinguishing clients from pools by the presence of a _connected property. See this code.

This feels a bit hacky, so I'd be happy to hear of a better way. If there is none, perhaps a type property could be added to clients and pools (and perhaps all other classes) in a future release?