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

From Stephen Frost
Subject Re: WIP Patch: Add a function that returns binary JSONB as a bytea
Date
Msg-id 20181031133056.GU4184@tamriel.snowman.net
Whole thread Raw
In response to Re: WIP Patch: Add a function that returns binary JSONB as a bytea  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: WIP Patch: Add a function that returns binary JSONB as a bytea
List pgsql-hackers
Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Kevin Van <kevinvan@shift.com> writes:
> > This patch adds a new function that allows callers to receive binary jsonb.
> > This change was proposed in the discussion here:
> > https://www.postgresql.org/message-id/CAOsiKEL7%2BKkV0C_hAJWxqwTg%2BPYVfiGPQ0yjFww7ECtqwBjb%2BQ%40mail.gmail.com
> > and the primary motivation is to reduce database load by skipping jsonb to
> > string conversion (with the expectation that the application can parse
> > binary jsonb).
>
> I dunno, I do not think it's a great idea to expose jsonb's internal
> format to the world.  We intentionally did not do that when the type
> was first defined --- that's why its binary I/O format isn't already
> like this --- and I don't see that the tradeoffs have changed since then.
> The format is complex, and specific to Postgres' needs, and we might wish
> to change it in future.

I disagree- it's awfully expensive to go back and forth between string
and a proper representation.  If we did decide to change the on-disk
format, we'd likely be able to translate that format into the
wire-protocol format and that'd still be much better than going to
strings.

As I recall, we did end up making changes to jsonb right before we
released it and so, at the time, it was definitely a good thing that we
hadn't exposed that format, but we're quite a few years in now (by the
time 12 comes out, every supported release will have jsonb) and the
format hasn't changed further.

If we really did want to go to a new format in the future, we'd probably
end up wanting to do so in a way which allowed us to avoid a full
dump/restore of the database too, so we'd need code to be able to at
least convert from the old format into the new format and it'd hopefully
not be too bad to have code to go the other way too.  Even if we didn't
though, I expect library authors would deal with the update across a
major version change- it's not like we don't do other things that
require them to update (SCRAM being my current favorite) and they've
been pretty good about getting things updated.

As always, there'll be the fallback option of going back to text format
too.

Thanks!

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Super PathKeys (Allowing sort order through precision lossfunctions)
Next
From: Andrew Dunstan
Date:
Subject: Re: pg_dumpall --exclude-database option