Hi,
On Fri, 9 Oct 2020 at 14:46, Andres Freund <and...@anarazel.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
