Re: WIP Patch: Add a function that returns binary JSONB as a bytea

Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
> On Wed, Oct 31, 2018 at 10:23 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
>> It's entirely unacceptable afaict. Besides the whole "exposing
>> internals" issue, it's also at least not endianess safe, depends on the
>> local alignment requirements (which differ both between platforms and
>> 32/64 bit), numeric's internal encoding and probably more.

> Binary format consuming applications already have to deal with these
> kinds of issues. We already expose internal structures in the other
> functions -- not sure why jsonb is held to a different standard.

I don't think it's being held to a different standard at all. Even for
data as simple as integers/floats, we convert to uniform endianness on the
wire. Moreover, we do not expose the exact bits for anything more complex
than machine floats. Numeric, for instance, gets disassembled into fields
rather than showing the exact header format (let alone several different
header formats, as actually found on disk).

Andres' point about alignment is a pretty good one as well, if it applies
here --- I don't recall just what internal alignment requirements jsonb
has. We have not historically expected clients to have to deal with that.

I agree that in any particular use-case one could argue for a different
set of trade-offs in choosing the exposed binary format. But this is the
set that the project has chosen, and one would need to make a FAR stronger
case than has been made here to let jsonb be an exception.

regards, tom lane