public inbox for [email protected]
help / color / mirror / Atom feedFrom: Peter Eisentraut <[email protected]>
To: Dave Cramer <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: pgsql-hackers <[email protected]>
Cc: Vladimir Sitnikov <[email protected]>
Cc: Shay Rojansky <[email protected]>
Cc: Mark Paluch <[email protected]>
Subject: Re: dynamic result sets support in extended query protocol
Date: Fri, 23 Oct 2020 10:59:38 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <CADK3HH++n5iKy18i6cF5ZQKQLZQ3n8k9n42G8eWsxxBvp5RX7g@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<CADK3HHKap0kzFKnHHEE94vb0ZL_sgdoJBVQT-PHWNt-kCkJAyQ@mail.gmail.com>
<[email protected]>
<CADK3HHLgQ81rvsDqHr9XcS=mgR5hQXz1x4pv2vWKQOacaT8ETQ@mail.gmail.com>
<[email protected]>
<CADK3HH++n5iKy18i6cF5ZQKQLZQ3n8k9n42G8eWsxxBvp5RX7g@mail.gmail.com>
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
view thread (30+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: dynamic result sets support in extended query protocol
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox