Re: dynamic result sets support in extended query protocol

Hi,

On Fri, 9 Oct 2020 at 14:46, Andres Freund <andres(at)anarazel(dot)de> wrote:

> Hi,
>
> On 2020-10-08 09:46:38 +0200, Peter Eisentraut wrote:
> > New would be that the server would now also respond with a new message,
> say,
> >
> > S: DynamicResultInfo
>
> > Now, if the client has seen DynamicResultInfo earlier, it should now go
> into
> > a new subsequence to get the remaining result sets, like this (naming
> > obviously to be refined):
>
> Hm. Isn't this going to be a lot more latency sensitive than we'd like?
> This would basically require at least one additional roundtrip for
> everything that *potentially* could return multiple result sets, even if
> no additional results are returned, right? And it'd add at least one
> additional roundtrip for every result set that's actually sent.
>

Agreed as mentioned.

>
> Is there really a good reason for forcing the client to issue
> NextResult, Describe, Execute for each of the dynamic result sets? It's
> not like there's really a case for allowing the clients to skip them,
> right? Why aren't we sending something more like
>
> S: CommandPartiallyComplete
> S: RowDescription
> S: DataRow...
> S: CommandPartiallyComplete
> S: RowDescription
> S: DataRow...
> ...
> S: CommandComplete
> C: Sync
>
> gated by a _pq_ parameter, of course.
>
>
> > I think this would all have to use the unnamed portal, but perhaps there
> > could be other uses with named portals. Some details to be worked out.
>
> Which'd avoid this too, but:
>
> > One thing that's missing in this sequence is a way to specify the desired
> > output format (text/binary) for each result set.
>
> Is a good point. I personally think avoiding the back and forth is more
> important though. But if we could address both at the same time...
>
>
> > (I suspect what would be more useful in practice is to designate
> > output formats per data type.)
>
> Yea, that'd be *really* useful. It sucks that we basically require
> multiple round trips to make realistic use of the binary data for the
> few types where it's a huge win (e.g. bytea).
>

Yes!!! Ideally in the startup message.

Dave