Re: jsonb and nested hstore

On Monday, February 10, 2014, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:

> On 2014-02-10 19:01:48 -0600, Merlin Moncure wrote:
> > On Mon, Feb 10, 2014 at 6:39 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us<javascript:;>>
> wrote:
> > > Merlin Moncure <mmoncure(at)gmail(dot)com <javascript:;>> writes:
> > >> On Mon, Feb 10, 2014 at 6:24 PM, Andres Freund <
> andres(at)2ndquadrant(dot)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