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

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kevin Van <kevinvan(at)shift(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: WIP Patch: Add a function that returns binary JSONB as a bytea
Date: 2018-10-31 13:30:56
Message-ID: 20181031133056.GU4184@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greetings,

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Kevin Van <kevinvan(at)shift(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2018-10-31 14:16:49 Re: pg_dumpall --exclude-database option
Previous Message Tomas Vondra 2018-10-31 13:18:35 Re: Super PathKeys (Allowing sort order through precision loss functions)