Re: jsonb and nested hstore

On Mon, Feb 10, 2014 at 12:15 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
>> On Mon, Feb 10, 2014 at 6:39 AM, Andres Freund <andres(at)2ndquadrant(dot)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