On Wed, Mar 24, 2021 at 10:58 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> 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, and that is exactly > what they'll get back.
OK. > 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't we solve this by recommending that clients using > this feature always double-check which format they actually got? > ISTM that the use-cases for the feature involve checking what data > type you got anyway, so that's not an unreasonable added requirement. I suppose that's a fair idea, but to me it still feels a bit like a round peg in the square hole. Suppose for example that there's a client application which wants to talk to a connection pooler which in turn wants to talk to the server. Let's also suppose that connection pooler isn't just a pass-through, but wants to redirect client connections to various servers or even intercept queries and result sets and make changes as the data passes by. It can do that by parsing SQL and solving the halting problem, whereas if this were a protocol-level option it would be completely doable. Now you could say "well, by that argument, DateStyle ought to be a protocol-level option, too," and that's pretty a pretty fair criticism of what I'm saying here. On the other hand, I'm not too sure that wouldn't have been the right call. Using SQL to tailor the wire protocol format feels like some kind of layering inversion to me. I think we should be working toward a state where it's more clear which things are "owned" at the wire protocol level and which things are "owned" at the SQL level, and this seems to be going in exactly the opposite direction, and in fact probably taking things further in that direction than we've ever gone before. -- Robert Haas EDB: http://www.enterprisedb.com
