On Sun, 7 Aug 2022 at 09:58, Robert Haas wrote:
> On Wed, Mar 24, 2021 at 12:01 PM Tom Lane wrote:
> > I don't think I buy the premise that there are exactly two levels
> > on the client side.
>
> Thanks for sharing your thoughts on this. I agree it's a complex
> issue, and the idea that there a
On Wed, Mar 24, 2021 at 12:01 PM Tom Lane wrote:
> I don't think I buy the premise that there are exactly two levels
> on the client side.
Thanks for sharing your thoughts on this. I agree it's a complex
issue, and the idea that there are possibly more than two logical
levels is, for me, maybe yo
Robert Haas writes:
> On Wed, Mar 24, 2021 at 10:58 AM Tom Lane wrote:
>> A client that is sending -1 and assuming that it will get back
>> a particular format could get broken if the GUC doesn't have the
>> value it thinks, true. But I'd argue that such code is unreasonably
>> non-robust. Can'
On Wed, Mar 24, 2021 at 10:58 AM Tom Lane wrote:
> Robert Haas writes:
> > But ... if it's just a GUC, it can be set by code on the server side
> > that the client knows nothing about, breaking the client. That seems
> > pretty bad to me.
>
> It's impossible for the proposed patch to break *exist
Robert Haas writes:
> But ... if it's just a GUC, it can be set by code on the server side
> that the client knows nothing about, breaking the client. That seems
> pretty bad to me.
It's impossible for the proposed patch to break *existing* clients,
because they all send requested format 0 or 1,
On Thu, Nov 5, 2020 at 3:49 PM Peter Eisentraut
wrote:
> We could also make it a protocol message, but it would essentially
> implement the same thing, just again separately. And then you'd have no
> support to inspect the current setting, test out different settings
> interactively, etc. That s
I think this is a good feature that would be useful to JDBC and more.
I don't know the surrounding code very well, but the patch looks good to me.
I agree with Tom Lane that the name of the variable is too verbose.
Maybe "auto_binary_types" is enough. Do we gain much by prefixing
"result_format_
On 21.03.21 20:18, Emre Hasegeli wrote:
Could you look into the log files in that test directory what is going
on?
Command 'test-result-format' not found in
/Users/hasegeli/Developer/postgres/tmp_install/Users/hasegeli/.local/pgsql/bin,
/Users/hasegeli/.local/bin, /opt/homebrew/bin, /usr/local/
> Could you look into the log files in that test directory what is going
> on?
Command 'test-result-format' not found in
/Users/hasegeli/Developer/postgres/tmp_install/Users/hasegeli/.local/pgsql/bin,
/Users/hasegeli/.local/bin, /opt/homebrew/bin, /usr/local/bin,
/usr/bin, /bin, /usr/sbin, /sbin,
On 19.03.21 15:55, Emre Hasegeli wrote:
I applied the patch, tried running the test and got the following:
rm -rf
'/Users/hasegeli/Developer/postgres/src/test/modules/libpq_extended'/tmp_check
/bin/sh ../../../../config/install-sh -c -d
'/Users/hasegeli/Developer/postgres/src/test/modules/li
I applied the patch, tried running the test and got the following:
rm -rf
'/Users/hasegeli/Developer/postgres/src/test/modules/libpq_extended'/tmp_check
/bin/sh ../../../../config/install-sh -c -d
'/Users/hasegeli/Developer/postgres/src/test/modules/libpq_extended'/tmp_check
cd . &&
TESTDIR='/U
On 09.03.21 19:04, Tom Lane wrote:
The implementation feels weird though, mainly in that I don't like
Peter's choices for where to put the code. pquery.c is not where
I would have expected to find the support for this, and I do not
have any confidence that applying the format conversion while
fi
David Steele writes:
> Andrew, Tom, does the latest patch address your concerns?
[ reads patch quickly... ] I think the definition is fine now,
modulo possible bikeshedding on the GUC name. (I have no
great suggestion on that right now, but the current proposal
seems mighty verbose.)
The imple
On 11/25/20 2:06 AM, Peter Eisentraut wrote:
On 2020-11-16 16:15, Andrew Dunstan wrote:
I think this is conceptually OK, although it feels a bit odd.
Might it be better to have the values as typename={binary,text} pairs
instead of oid={0,1} pairs, which are fairly opaque? That might make
things
On 2020-11-16 16:15, Andrew Dunstan wrote:
I think this is conceptually OK, although it feels a bit odd.
Might it be better to have the values as typename={binary,text} pairs
instead of oid={0,1} pairs, which are fairly opaque? That might make
things easier for things like UDTs where the oid mig
On 11/9/20 5:10 AM, Peter Eisentraut wrote:
> On 2020-11-05 22:03, Peter Eisentraut wrote:
>>> 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 wa
On 2020-11-05 22:03, Peter Eisentraut wrote:
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
čt 5. 11. 2020 v 21:48 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> On 2020-10-26 09:45, Pavel Stehule wrote:
> > The attached patch implements this. For example, to get int2, int4,
> > int8 in binary by default, you could set
> >
> > SET default_result_fo
On 2020-10-26 15:35, Tom Lane wrote:
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 ...
It does feel that way, but it gets the job done well and you can use all
On 2020-10-26 09:45, Pavel Stehule wrote:
The attached patch implements this. For example, to get int2, int4,
int8 in binary by default, you could set
SET default_result_formats = '21=1,23=1,20=1';
Using SET statement for this case looks very obscure :/
This is a protocol related
Peter Eisentraut 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 wo
po 26. 10. 2020 v 9:31 odesílatel Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> napsal:
> During the discussion on dynamic result sets[0], it became apparent that
> the current way binary results are requested in the extended query
> protocol is too cumbersome for some practical uses, and k
22 matches
Mail list logo
