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> wrote: > > Merlin Moncure <mmonc...@gmail.com> writes: > >> On Mon, Feb 10, 2014 at 6:24 PM, Andres Freund <and...@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.
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, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
