Re: jsonb and nested hstore

On Mon, Feb 10, 2014 at 12:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>> On Mon, Feb 10, 2014 at 6:39 AM, Andres Freund <andres@2ndquadrant.com> wrote:
>>> On 2014-02-10 07:27:59 -0500, Andrew Dunstan wrote:
>>>> Teodor privately suggested something similar.  I was thinking of just
>>>> sending a version byte, which for now would be '\x01'. An int8 seems like
>>>> more future-proofing provision than we really need.
>
>> -1.   Currently no other wire format types send version and it's not
>> clear why this one is special.  We've changed the wire format versions
>> before and it's upon the client to deal with those changes.
>
> Really?  How would you expect to do that, exactly?  In particular,
> how would you propose that a binary pg_dump file be reloadable if
> we redefine the binary format down the road without having made
> provision like this?
>
>> Versioning one type only IMNSHO is a complete hack.
>
> I don't feel a need for versioning int, or float8, or most other types;
> and that includes the ones for which we've previously defined binary
> format as equivalent to text (enums).  In this case we know that we're not
> totally satisfied with the binary format we're defining today, so I think
> a type-specific escape hatch is a reasonable solution.
>
> Moreover, I don't especially buy tying it to server version, even if we
> had an information pathway that would provide that reliably in all
> contexts.

Why not?  Furthermore what are we doing now?  If we need a binary
format contract that needs to be separated from this discussion.

I've written (along with Andrew C) the only serious attempt to deal
with client side binary format handling (http://libpqtypes.esilo.com/)
and in all interesting cases it depends on the server version to
define binary parsing behaviors.   I agree WRT float8, etc but other
types have changed in a couple of cases and it's always been with the
version.   I find it highly unlikely that any compatibility behaviors
are going to be defined *for each and every returned datum* now, or
ever...so even if it's a few bytes lost, why do it?  Intra-version
compatibility issues should they ever have to be handled would be more
likely handled at connection- or query- time.

Point being, if an escape hatch is needed, I'm near 100% certain this
is not the right place to do it.  Binary wire format compatibility is
a complex topic and proposed solution ISTM is not at all fleshed out.

merlin