Andrew Chernow <ac@esilo.com> 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
