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