Re: jsonb and nested hstore

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. Granting the presumption that more than one data type would
want such versioning, it's still possible that different data types would
have different ideas about what they needed to do and where the cutover
points were.

regards, tom lane