On 2014-02-10 17:48:32 -0600, Merlin Moncure wrote:
> On Mon, Feb 10, 2014 at 5:38 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> > On 2014-02-10 17:35:12 -0600, Merlin Moncure wrote:
> >> Wrong. You still need to have code that checks the server version and
> >> see if it's supported (particularly for sending) and as there is *no
> >> protocol negotiation of the formats at present it's all going to boil
> >> down to if version = X do Y*. How does the server know which
> >> 'versions' are ok to send? It doesn't. Follow along with me here:
> >> Suppose we don't introduce a version flag today and change the format
> >> to some more exotic structure for 9.5. How has the version flag made
> >> things easier for the client? It hasn't. The client goes "if version
> >> = X do Y".
> >
> > think of binary COPY outputting data in 9.4 and then trying to import
> > that data into 9.5. That's the interesting case here.
>
> right, json could be made work, but any other format change introduced
> to any other already existing type will break. That's not a real
> solution unless we decree henceforth that no formats will change from
> here on in, in which case I withdraw my objection.
Sure, it's not a full solution. But it's better than nothing, and it's
likely that we'll see breakage soonish. I don't think there's been much
recent mucking around with incompatible binary formats?
> I think COPY binary has exactly the same set of considerations as the
> client side. If you want to operate cleanly between versions (which
> has never been promised in the past), you have to encode in a header
> the kinds of things the server would need to parse it properly.
> Starting with, but not necessarily limited to, the encoding server's
> version.
It works in enough cases atm that it's worthwile trying to keep it
working. Sure, it could be better, but it's what we have right now. Atm
it's e.g. the only realistic way to copy larger amounts of bytea between
servers without copying the entire cluster.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
