Allow JSON/JSONB serialization and deserialization in the PostgreSQL adapter to be handled by library consumers

[justindbelanger]

I've integrated Hyak2, via its PostgreSQL adapter, into an application that already manages serialization and deserialization of JSON/JSONB data. Hyak2's PostgreSQL adapter assumes that it is responsible for doing this on its own.
Because of this, when I try to check the enabled? status for a feature flag, I get an uncaught exception, as the Hyak2 PostgreSQL adapter tries to deserialize a Clojure hash map. See this gist for the full stack trace: https://gist.github.com/justindbelanger/d016e135e4d60fea5fba1c8baaf8cd95

I would like to see support for this use case; that is, the ability to allow consumers of this library to handle the serialization and deserialization.

As further background information, Hyak2's PostgreSQL adapter is also being used in another application that does not yet manage its own serialization and deserialization of JSON/JSONB data, so I would prefer support for both situations.

[rgm]

Thanks for finding this.

I'm thinking the right thing to do is an option disable-serialization? to opt out of the internal JSON handling, since that direction wouldn't break existing code. (Versus, say, enable-serialization? which would).

The change is pretty straightforward, but I'm needing a bit of help/research testing it. The problem is that if I enable the next.jdbc-suggested protocol extensions, those are JVM level, so I have to figure out how to isolate that.

[rgm]

Figured it out: I can opt into and out of using serialization for tests with a dynamic var that the ->json and <-json functions use to decide whether to do their thing or just act like identity, plus bind.