DynamicWriteStrategy

When an object registered as a dynamic type is written as one without being asked to be.

This governs the write side only. Reading needs no policy: a value comes back as a dynamic_dto because the column is one, and the discriminator inside it names the class - neither of which depends on what the calling code declared.

Writing has no such anchor. The driver declares the types of the parameters it sends rather than asking the server what it wants, so at a top-level parameter there is no expected type to consult and the Kotlin class is the only thing to go on. Where a class is registered here and as a composite, that is not enough to say which of the two was meant, and this is what settles it.

A mode therefore reaches only as far as that ignorance does. An attribute of a composite, an element of an array and a value wrapped in PgTyped all carry the type they are going into, and that type decides: a class is written as a dynamic_dto there when the destination is one and as the composite when it is that, under every mode alike.

DynamicTypes.toDynamicDto overrides whichever mode is in force: a value already wrapped is written as a dynamic_dto under all three.

A mode is given to a client and goes with every class registered through it: that class is written on that mode whichever client a query runs through. A class is registered once per database, so a second client registering it on another mode is refused rather than overriding the first.