On 11/02/2018 05:20 PM, Andres Freund wrote:
> Hi,
>
> On 2018-11-02 17:02:24 -0400, Andrew Dunstan wrote:
>> On 11/02/2018 11:34 AM, Merlin Moncure wrote:
>>> Binary format consuming applications already have to deal with these
>>> kinds of issues. We already expose internal structures in the other
>>> functions -- not sure why jsonb is held to a different standard. For
>>> other data types where format changes were made, the standard of
>>> 'caveat version' was in place to protect the user. 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.
>>>
>>
>> jsonb_send does output a version header, as I pointed out upthread.
> That's Merlin's point I think. For reasons I don't quite understand he
> doesn't like that. Yes, a global solution would have been prettier than
> per-datum version flag, but that obvioulsy wasn't realistic to introduce
> around the feature freeze of the version that introduced jsonb.
>
>
>
Oh, hmm. It would have been a big change of little value, ISTM. One byte
of overhead per jsonb datum for a version indicator doesn't seem a huge
price to pay.
cheers
andtrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services