On Mon, Apr 3, 2023 at 11:29 AM Dave Cramer <davecra...@gmail.com> wrote:
> > participating clients to receive GUC configured format. I do not > >> > think that libpq's result format being able to be overridden by GUC >>> > is a good idea at all, the library has to to participate, and I >>> > think can be made to so so without adjusting the interface (say, by >>> > resultFormat = 3). >>> >>> Interesting idea. I suppose you'd need to specify 3 for all result >>> columns? That is a protocol change, but wouldn't "break" older clients. >>> The newer clients would need to make sure that they're connecting to >>> v16+, so using the protocol version alone wouldn't be enough. Hmm. >>> >> >> > So this only works with extended protocol and not simple queries. > Again, as Peter mentioned it's already easy enough to confuse psql using > binary cursors so > it makes sense to fix psql either way. > > If you use resultFormat (3) I think you'd still end up doing the Describe > (which we are trying to avoid) to make sure you could receive all the > columns in binary. > Can you elaborate on why Describe would have to be passed? Agreed that would be a dealbreaker if so. If you pass a 3 sending it in, the you'd be checking PQfformat on data coming back as 0/1, or at least that's be smart since you're indicating the server is able to address the format. This addresses the concern libpq clients currently passing resultfomat zero could not have that decision overridden by the server which I also think is a dealbreaker. There might be other reasons why a describe message may be forced however. merlin
