Re: jsonb and nested hstore - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: jsonb and nested hstore
Date
Msg-id CAHyXU0wUPqESRC-wrbHvDHp0sZL+kKmz=9Wb6DH29Jj+o1O3AQ@mail.gmail.com
Whole thread Raw
In response to Re: jsonb and nested hstore  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: jsonb and nested hstore
Re: jsonb and nested hstore
List pgsql-hackers
On Mon, Feb 10, 2014 at 6:39 AM, Andres Freund <andres@2ndquadrant.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.

merlin



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Memory ordering issue in LWLockRelease, WakeupWaiters, WALInsertSlotRelease
Next
From: Tom Lane
Date:
Subject: Re: Memory ordering issue in LWLockRelease, WakeupWaiters, WALInsertSlotRelease