Andrew Chernow <[EMAIL PROTECTED]> writes: > For starters, if binary results is a feature you wish you could uninvent > then we are probably dead in the water for that reason. This goes to > the core of our concept.
Not really: AFAICS you could implement exactly the API you have sketched without any reliance on binary data transmission whatsoever. As long as PGparam is an opaque struct, library users would have no idea whether the values they provide are being sent as text or binary. You should probably take two steps back and think about what aspects of what you want to do are really involved with providing an easier-to-use API for PQexecParams and friends, and what parts are actually interested in binary data transmission (and why). Separating those issues in your mind might produce more clarity. > In the end, some of these changes would change the text format right? I'd consider that fairly unlikely. For instance, the money width change didn't impact the text format (except to the extent that longer values are now legal), and remembering a timestamptz's zone wouldn't impact the text representation either. Another example is that any significant re-implementation of type NUMERIC (say, as a bignum integer plus exponent instead of the current BCD-ish format) would probably change its binary representation, but there'd be no need for a text change. The bottom line to me is that binary representations are inherently a lot more fragile and version-dependent than text representations. Our attitude so far has been that client-side code that wants to use binary data transmission is taking all the risk of changes on itself. ("If it breaks, you get to keep both pieces.") It's not clear to me what we gain by making libpq subject to those risks. If we could have libpq insulate client apps from these kinds of changes, that would be one thing; but AFAICS, with these more complex types, a binary format change would usually also dictate a change in what the library exposes to clients. As far as I saw, your proposal completely glossed over the issue of exactly what data structure would be exposed to clients for anything more complex than an integer. I'm afraid that that structure would be subject to change, and then we'd just have two layers of brokenness on our hands instead of only one. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend