Re: WIP Patch: Add a function that returns binary JSONB as a bytea
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Merlin Moncure <mmoncure@gmail.com>
Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, Stephen Frost <sfrost@snowman.net>, kevinvan@shift.com, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-11-02T21:15:41Z
Lists: pgsql-hackers
On 2018-11-02 10:34:07 -0500, Merlin Moncure wrote: > 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. Uh, which? We have some that are affected by configure flags, but otherwise we should be endianess & alignment independent. And *even if* that were the case, that's not a good reason to continue a bad practice. > 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. What's the problem with the version? How does a COPY BINARY flag address normal clients? Greetings, Andres Freund
Commits
-
Build de-escaped JSON strings in larger chunks during lexing
- 3838fa269c15 16.0 landed