Re: default result formats setting - Mailing list pgsql-hackers

From Tom Lane
Subject Re: default result formats setting
Date
Msg-id 685646.1603722932@sss.pgh.pa.us
Whole thread Raw
In response to default result formats setting  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: default result formats setting
List pgsql-hackers
Peter Eisentraut <peter.eisentraut@2ndquadrant.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



pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: libpq compression
Next
From: Tom Lane
Date:
Subject: Re: Should the function get_variable_numdistinct consider the case when stanullfrac is 1.0?