Re: jsonb and nested hstore

On 2014-02-10 11:59:53 -0600, Merlin Moncure wrote:
> On Mon, Feb 10, 2014 at 6:39 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> > On 2014-02-10 07:27:59 -0500, Andrew Dunstan wrote:
> >> On 02/10/2014 05:05 AM, Andres Freund wrote:
> >> >I'd suggest making the format discernible from possible different future
> >> >formats, to allow introducing a proper binary at some later time. Maybe
> >> >just send a int8 first, containing the format.
> >> >
> >>
> >> Teodor privately suggested something similar. I was thinking of just
> >> sending a version byte, which for now would be '\x01'. An int8 seems like
> >> more future-proofing provision than we really need.
> >
> > Hm. Isn't that just about the same? I was thinking of the c type int8,
> > not the 64bit type. It seems cleaner to do a pg_sendint(..., 1, 1) than
> > to do it manually inside the string.
>
> -1. Currently no other wire format types send version and it's not
> clear why this one is special. We've changed the wire format versions
> before and it's upon the client to deal with those changes. The
> server version *is* the version basically. If a broader solution
> exists I think it should be addressed broadly. Versioning one type
> only IMNSHO is a complete hack.

I don't find that very convincing. The entire reason jsonb exists is
because the parsing overhead of text json is significant, so it stands
to reason that soon somebody will try to work on a better wire protocol,
even if the current code cannot be made ready for 9.4. And I don't think
past instability of binary type's formats is a good reason for
*needlessly* breaking stuff like binary COPYs.
And it's not like one prefixed byte has any real-world relevant cost.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services