Jeremy Taylor

This is worth checking again now that https://github.com/xtdb/xtdb/issues/3582 seems resolved on edge/nightly/soon-b2

Any real requirements for using array types should be unblocked by transit (as a comprehensive workaround) for now, so this is not a priority.

Following @mbutlerw's change in https://github.com/xtdb/xtdb/commit/0c0010e9f860197230ecbd43a3de0e6aa25b4ac7#diff-1a8ccbf1b5d5b6dd1cb8a2c0200c29a783994c1c1e59b78d8aa82e0e6f3f6003R1592 - the code above now errors intentionally with "Missing types for params" However note there's an "Uncaught exception"/NPE logged on the server: ``` 16:18:03 |...

As a satisfactory workaround (vs. attempting any upstream changes to psycopg), strings can now be used ~normally by simply configuring to use the varchar OID code path instead, using `connection.adapters.register_dumper(str,...

Related bug, attempting to writing a boolean `True` will (silently) result in: ``` java.lang.NullPointerException: Cannot invoke "clojure.lang.IFn.invoke(Object, Object)" because "read_binary" is null at xtdb.pgwire$__GT_xtify_param$xtify_param__34005.invoke(pgwire.clj:1094) at clojure.core$map_indexed$mapi__8676$fn__8677.invoke(core.clj:7500) at clojure.lang.LazySeq.force(LazySeq.java:50) at clojure.lang.LazySeq.realize(LazySeq.java:89)...

@jarohen done - also noted the workaround in the example. I believe it's simply now the ~same issue as with attempting to use Node's `pg`, where no type info is...

Let's keep this in mind as (e.g.) I haven't yet found a workable C# driver approach and it could unlock many more drivers

Related: https://github.com/xtdb/xtdb/issues/3532 (I don't think this change alone necessarily solves everything though)

This should also add logging for pgwire errors which are sent back to the client but otherwise never logged, e.g. protocol violations (not all clients or drivers handle/return the `:message`...

As discussed, we want a simpler approach for this than the custom logback