Re: default result formats setting

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: default result formats setting
Дата
Msg-id 685646.1603722932@sss.pgh.pa.us
обсуждение исходный текст
Ответ на default result formats setting  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: default result formats setting  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Konstantin Knizhnik
Дата:
Сообщение: Re: libpq compression
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Should the function get_variable_numdistinct consider the case when stanullfrac is 1.0?