On Mon, Feb 10, 2014 at 6:39 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>> On Mon, Feb 10, 2014 at 6:24 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>>> And if we add a new format version in 9.5 we need to make it discernible
>>> from the 9.4 format. Without space for a format indicator we'd have to
>>> resort to ugly tricks like defining the high bit in the first byte set
>>> indicates the new version. I don't see the improvement here.
>
>> Point being: a 9.5 binary format reading server could look for a magic
>> token in the beginning of the file which would indicate the presence
>> of a header. The server could then make intelligent decisions about
>> reading data inside the file which would be follow exactly the same
>> kinds of decisions binary format consuming client code would make.
>> Perhaps it would be a simple check on version, or something more
>> complex that would involve a negotiation. The 'format' indicator,
>> should version not be precise enough, needs to be in the header, not
>> passed with every instance of the data type, and certainly not for one
>> type in the absence of others.
>
> Basically, you want to move the goalposts to somewhere that's not only
> out of reach today, but probably a few counties away from the stadium.
> I don't see this happening at all frankly, because nobody has been
> interested enough to work on something like it up to now. And I
> definitely don't see it as appropriate to block improvement of jsonb
> until this happens.
That's completely unfair. I'm arguing *not* to attach version
dependency expectations to the jsonb type, at all, not the other way
around. If you want to do that, fine, but do it *later* as in, 9.5,
or beyond. I just gave an example of how binary format changes could
be worked in later.
merlin
