Re: WIP Patch: Add a function that returns binary JSONB as a bytea - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: WIP Patch: Add a function that returns binary JSONB as a bytea
Date
Msg-id CAHyXU0yfb=Nst7CXXzxTv0hOF4Amk6LoS8weZK-CNqG1--OibA@mail.gmail.com
Whole thread Raw
In response to Re: WIP Patch: Add a function that returns binary JSONB as a bytea  (Andres Freund <andres@anarazel.de>)
Responses Re: WIP Patch: Add a function that returns binary JSONB as a bytea  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: WIP Patch: Add a function that returns binary JSONB as a bytea  (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>)
Re: WIP Patch: Add a function that returns binary JSONB as a bytea  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Wed, Oct 31, 2018 at 10:23 AM Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> On 2018-10-31 11:13:13 -0400, Andrew Dunstan wrote:
> > I agree that just sending a blob of the internal format isn't a great idea.
>
> 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.  For
other data types where format changes were made, the standard of
'caveat version' was in place to protect the user.  For jsonb we
decided to implement a version flag within the type itself, which I
thought mistake at the time -- better to have a version header in the
COPY BINARY if needed.

People using binary format are basically interested one one thing,
performance.  It's really the fastest way to get data in an out of the
database.  For my part, I'd like to see some observed demonstrable
benefit in terms of performance to justify making the change.

merlin


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PG vs macOS Mojave
Next
From: Jakob Egger
Date:
Subject: Re: PG vs macOS Mojave