On Monday, February 10, 2014, Andres Freund <and...@2ndquadrant.com> wrote:
> On 2014-02-10 19:01:48 -0600, Merlin Moncure wrote: > > On Mon, Feb 10, 2014 at 6:39 PM, Tom Lane <t...@sss.pgh.pa.us<javascript:;>> > wrote: > > > Merlin Moncure <mmonc...@gmail.com <javascript:;>> writes: > > >> On Mon, Feb 10, 2014 at 6:24 PM, Andres Freund < > and...@2ndquadrant.com <javascript:;>> 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. > > Comeon. Your way requires building HEAPS of new and generic > infrastructure in 9.5 and would only work for binary copy. The proposed > way requires about two lines of code. Without the generic infrastructure > we'd end up relying on some intracacies like the meaning of high bit in > the first byte or such. > > Anyway, that's it on this subthread from me > Fair enough. I'll concede the point. merlin