Re: default result formats setting

po 26. 10. 2020 v 9:31 odesílatel Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)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 keeping that
> style around would also make the proposed protocol extensions very
> complicated.
>
> The premise here is that a client library has hard-coded knowledge on
> how to deal with binary format for certain, but not all, data types.
> (Most client libraries process everything in text, and some client
> libraries process everything in binary. Neither of these extremes are
> of concern here.) Such a client always has to request a result row
> description (Describe statement) before sending a Bind message, in order
> to be able to pick out the result columns in should request in binary.
> The feedback was that this extra round trip is often not worth it in
> terms of performance, and so it is not done and binary format is not
> used when it could be.
>
> 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.
> 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.
>
> 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 issue, and should be solved by protocol
extending. I don't think so SQL level is good for that.

More, this format is not practical for custom types, and the list can be
pretty long.

> This is a list of oid=format pairs.
>
> I think this format satisfies the current requirements of the JDBC
> driver. But the format could also be extended in the future to allow
> type names to be listed or some other ways of identifying the types.
>
> In order to be able to test this via libpq, I had to add a little hack.
> Currently, PQexecParams() and similar functions can only pass exactly
> one result format code, which per protocol is then applied to all result
> columns. There is no support for sending zero result format codes to
> make the session default apply. I enabled this by allowing -1 to be
> passed as the format code. I'm not sure if we want to make this part of
> the official API, but it would be useful to have something like this
> somehow.
>

+1 to this feature, but -1 for design. It should be solved on protocol
level.

Regards

Pavel

>
>
> [0]:
>
> https://www.postgresql.org/message-id/flat/6e747f98-835f-2e05-cde5-86ee444a7140%402ndquadrant.com
>
> --
> Peter Eisentraut http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>