Обсуждение: Wire protocol: type-specific opt-in to binary format
I would like to add functionality which allows a client to tell the server which types can be sent in binary format. The immediate goal is to suppress hex quoting for BYTEA values, but it seems to make sense to make this functionality more general. This doesn't have to be a flag on the wire protocol, it could be a regular run-time parameter. Do you think this would make sense? -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On Nov24, 2011, at 10:03 , Florian Weimer wrote: > I would like to add functionality which allows a client to tell the > server which types can be sent in binary format. The immediate goal is > to suppress hex quoting for BYTEA values, but it seems to make sense to > make this functionality more general. If you use the extended query protocol, the client can already choose text vs. binary representation on a per-column basis. You can query the result's column types by issuing a Describe message after the Parse message. For each column you can then decide whether you want textual or binary representation, and include that choice in the subsequent Bind message. best regards, Florian Pflug
* Florian Pflug: > On Nov24, 2011, at 10:03 , Florian Weimer wrote: >> I would like to add functionality which allows a client to tell the >> server which types can be sent in binary format. The immediate goal is >> to suppress hex quoting for BYTEA values, but it seems to make sense to >> make this functionality more general. > > If you use the extended query protocol, the client can already choose > text vs. binary representation on a per-column basis. You can query > the result's column types by issuing a Describe message after the > Parse message. For each column you can then decide whether you want > textual or binary representation, and include that choice in the > subsequent Bind message. Interesting. Doesn't this introduce another roundtrip? -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On Nov24, 2011, at 15:04 , Florian Weimer wrote: > * Florian Pflug: >> On Nov24, 2011, at 10:03 , Florian Weimer wrote: >>> I would like to add functionality which allows a client to tell the >>> server which types can be sent in binary format. The immediate goal is >>> to suppress hex quoting for BYTEA values, but it seems to make sense to >>> make this functionality more general. >> >> If you use the extended query protocol, the client can already choose >> text vs. binary representation on a per-column basis. You can query >> the result's column types by issuing a Describe message after the >> Parse message. For each column you can then decide whether you want >> textual or binary representation, and include that choice in the >> subsequent Bind message. > > Interesting. Doesn't this introduce another roundtrip? Yes. Maybe that's also something that should go on the next protocol version todo list. In any case, this is something that solely concerns the client library (libpq, JDBC, ...), not users of that library, and should thus be handled on the protocol level, not via a GUC. best regards, Florian Pflug
* Florian Pflug: >>> If you use the extended query protocol, the client can already choose >>> text vs. binary representation on a per-column basis. You can query >>> the result's column types by issuing a Describe message after the >>> Parse message. For each column you can then decide whether you want >>> textual or binary representation, and include that choice in the >>> subsequent Bind message. >> >> Interesting. Doesn't this introduce another roundtrip? > > Yes. Maybe that's also something that should go on the next protocol version > todo list. Okay. > In any case, this is something that solely concerns the client library > (libpq, JDBC, ...), not users of that library, and should thus be handled > on the protocol level, not via a GUC. How is this different from the bytea_output GUC? libpq doesn't hide that at all, but the JDBC driver does---similar to the text/binary distinction. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Florian Weimer <fweimer@bfk.de> writes:
> I would like to add functionality which allows a client to tell the
> server which types can be sent in binary format. The immediate goal is
> to suppress hex quoting for BYTEA values, but it seems to make sense to
> make this functionality more general.
> This doesn't have to be a flag on the wire protocol, it could be a
> regular run-time parameter.
> Do you think this would make sense?
No. Especially not as a GUC. People have gotten this idea that they
can whack behavior around arbitrarily under the control of some GUC or
other, and that won't break things and create security holes. Generally
that's way too optimistic, and I think it's way too optimistic in this
particular case. As near as I can tell, you are proposing a GUC that
will cause the server to flat-out violate the existing protocol
document, ie send something in binary when the client's request clearly
specified text (or perhaps vice versa). That is a recipe for breakage,
not a recipe for making anybody's life better.
It might be good to add some ability like this when we do the next set
of protocol revisions. But trying to pretend that it's not a protocol
change will lead to nothing but a dangerous kluge.
regards, tom lane