Christian Ohler <oh...@shift.com> writes:
> On Wed, Oct 31, 2018 at 7:22 AM Tom Lane <t...@sss.pgh.pa.us> wrote:
>> If we're going to expose the
>> internal format, let's just change the definition of the type's binary
>> I/O format, thereby getting a win for purposes like COPY BINARY as well.
> How would this work from the driver's and application's perspective? What
> does the driver do when receiving JSONB data?
Well, upthread it was posited that applications that read binary JSONB
data would be willing to track changes in that format (or else have no
need to, because they don't do anything with it except feed it back to the
server). If that isn't the case, then this entire thread is a waste of
time. I certainly don't buy that exposing the internal format via some
other mechanism than binary I/O would be a sufficient excuse for not
worrying about cross-version compatibility.
> The idea behind the proposal is to improve efficiency by avoiding
> conversions, and the most straightforward way to do that is for every layer
> to pass through the raw bytes.
This argument is, frankly, as bogus as it could possibly be. In the first
place, you're essentially saying that ignoring version compatibility
considerations entirely is the way to avoid future version compatibility
problems. I don't buy it. In the second place, you already admitted
that format conversion *is* necessary; what PG finds best internally is
unlikely to be exactly what some other piece of software will want.
So we'd be better off agreeing on some common interchange format.
I'm still bemused by the proposition that that common interchange format
shouldn't be, um, JSON. We've already seen BSON, BJSON, etc die
well-deserved deaths. Why would jsonb internal format, which was never
for one second intended to be seen anywhere outside PG, be a better
interchange-format design than those were?
(In short, I remain unconvinced that we'd not be better off spending
our effort on making json_out faster...)
regards, tom lane
