Re: default result formats setting

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: default result formats setting
Date: 2020-10-26 14:35:32
Message-ID: 685646.1603722932@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> The conceptual solution is to allow a client to register for a session
> which types it wants to always get in binary, unless it says otherwise.

OK.

> In the discussion in [0], I pondered a new protocol message for that,
> but after further thought, a GUC setting would do just as well.

I think a GUC is conceptually the wrong level ...

> In order to be able to test this via libpq, I had to add a little hack.

... which is part of the reason why you have to kluge this. I'm not
entirely certain which levels of the client stack need to know about
this, but surely libpq is one.

I'm also quite worried about failures (maybe even security problems)
arising from the "wrong level" of the client stack setting the GUC.

Independently of that, how would you implement "says otherwise" here,
ie do a single-query override of the session's prevailing setting?
Maybe the right thing for that is to define -1 all the way down to the
protocol level as meaning "use the session's per-type default", and
then if you don't want that you can pass 0 or 1. An advantage of that
is that you couldn't accidentally break an application that wasn't
ready for this feature, because it would not be the default to use it.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-10-26 14:37:06 Re: Should the function get_variable_numdistinct consider the case when stanullfrac is 1.0?
Previous Message Konstantin Knizhnik 2020-10-26 14:22:02 Re: libpq compression