Peter Eisentraut <peter_e@gmx.net> writes:
> I think the "future versions" in this are going to be making this choice a
> datatype-specific session state. How can we make this transition
> smoother? Maybe 0 can be default, 1 text, 2 binary?
Why would a variable default be a good idea? The client *always* wants
to know what format the data is being returned in; I can't imagine
wanting a default that might be unknown to (any layer of) client
software.
One of the things that I think I have learned from this redesign is
that hidden state variables that affect the low-level protocol are
a bad idea. If we were to provide a changeable default format, I'd
want it to be reported by ParameterStatus messages. But I don't really
see the argument for providing it. You'd just have to clutter the
client-side stack with mechanisms for finding out what the default is.
That's about the same amount of grunge in the API as labeling data with
the format code in the first place ... but it's a lot easier to shoot
yourself in the foot by forgetting to handle it.
regards, tom lane
