I'm submitting a ...
Describe the issue
I am developing an application that creates new composite types on the fly, and to transfer them over the wire I have a PGobject that implements PGBinaryObject. The problem is that, despite implementing this interface, they never get transferred with binary encoding. I've tracked this down to PgPreparedStatement.setPGobject which checks whether the type's oid is in the specific set of types marked for binary transfer. And that has to be set as a property at connection time.
Given the dynamic nature of the application, setting these properties would require me to connect twice: first to fetch the oids of all custom types, and then to reconnect with those oids in the properties. Worse than that, whenever a new type is created I would need to disconnect from the database and reconnect to reinitialize the set that QueryExecutorImpl holds.
It seems to me that a simple fix to this would be to simply change
if ((x instanceof PGBinaryObject) && connection.binaryTransferSend(oid)) {
to
if (x instanceof PGBinaryObject) {
and to similarly not require pre-initialized properties for binary types when receiving data.
I'm probably being naive; I haven't dug deeply into the code. But I feel like if you do implement PGBinaryObject then that should be sufficient indication that you want the data transferred in binary form.
If that won't work for some reason, at least being able to amend the set of binary-transfer types after you have already connected would be helpful.
I'm submitting a ...
Describe the issue
I am developing an application that creates new composite types on the fly, and to transfer them over the wire I have a PGobject that implements PGBinaryObject. The problem is that, despite implementing this interface, they never get transferred with binary encoding. I've tracked this down to PgPreparedStatement.setPGobject which checks whether the type's oid is in the specific set of types marked for binary transfer. And that has to be set as a property at connection time.
Given the dynamic nature of the application, setting these properties would require me to connect twice: first to fetch the oids of all custom types, and then to reconnect with those oids in the properties. Worse than that, whenever a new type is created I would need to disconnect from the database and reconnect to reinitialize the set that QueryExecutorImpl holds.
It seems to me that a simple fix to this would be to simply change
if ((x instanceof PGBinaryObject) && connection.binaryTransferSend(oid)) {to
if (x instanceof PGBinaryObject) {and to similarly not require pre-initialized properties for binary types when receiving data.
I'm probably being naive; I haven't dug deeply into the code. But I feel like if you do implement PGBinaryObject then that should be sufficient indication that you want the data transferred in binary form.
If that won't work for some reason, at least being able to amend the set of binary-transfer types after you have already connected would be helpful.