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
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 |