Re: dynamic result sets support in extended query protocol

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

> Hi,
>
> On 2020-10-09 14:49:11 -0400, Dave Cramer wrote:
> > On Fri, 9 Oct 2020 at 14:46, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > > > (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.
>
> I don't think startup is a good choice. For one, it's size limited. But
> more importantly, before having successfully established a connection,
> there's really no way the driver can know which types it should list as
> to be sent in binary (consider e.g. some postgis types, which'd greatly
> benefit from being sent in binary, but also just version dependent
> stuff).
>
> For the most part we know exactly which types we want in binary for 99% of
queries.

> The hard part around this really is whether and how to deal with changes
> in type definitions. From types just being created - comparatively
> simple - to extensions being dropped and recreated, with oids
> potentially being reused.
>

Fair point but this is going to be much more complex than just sending most
of the results in binary which would speed up the overwhelming majority of
queries

Dave Cramer

>
>