On Mon, Feb 10, 2014 at 12:15 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Merlin Moncure <mmonc...@gmail.com> writes: >> On Mon, Feb 10, 2014 at 6:39 AM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers