On 2020-10-20 12:24, Dave Cramer wrote:
Finally, we could do it an a best-effort basis. We use binary format
for registered types, until there is some invalidation event for the
type, at which point we revert to default/text format until the end
of a
session (or until another protocol message arrives re-registering the
type).
Does the driver tell the server what registered types it wants in binary ?
Yes, the driver tells the server, "whenever you send these types, send
them in binary" (all other types keep sending in text).
This should work, because the result row descriptor contains the
actual format type, and there is no guarantee that it's the same one
that was requested.
So how about that last option? I imagine a new protocol message, say,
TypeFormats, that contains a number of type/format pairs. The message
would typically be sent right after the first ReadyForQuery, gets no
response.
This seems a bit hard to control. How long do you wait for no response?
In this design, you don't need a response.
It could also be sent at any other time, but I expect that to
be less used in practice. Binary format is used for registered
types if
they have binary format support functions, otherwise text continues to
be used. There is no error response for types without binary support.
(There should probably be an error response for registering a type that
does not exist.)
I'm not sure we (pgjdbc) want all types with binary support functions
sent automatically. Turns out that decoding binary is sometimes slower
than decoding the text and the on wire overhead isn't significant.
Timestamps/dates with timezone are also interesting as the binary output
does not include the timezone.
In this design, you pick the types you want.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
