Re: 7.4 COPY BINARY Format Change - Mailing list pgsql-hackers

From Tom Lane
Subject Re: 7.4 COPY BINARY Format Change
Date
Msg-id 16160.1059755735@sss.pgh.pa.us
Whole thread Raw
In response to 7.4 COPY BINARY Format Change  (Lee Kindness <lkindness@csl.co.uk>)
Responses Re: 7.4 COPY BINARY Format Change  (Lee Kindness <lkindness@csl.co.uk>)
List pgsql-hackers
Lee Kindness <lkindness@csl.co.uk> writes:
> I've attached a patch which lets COPY read in the 7.1 format. However
> i'm not convinced this is the right way to go - I think the format
> which is output by 7.4 should be identical to the 7.1 format.

You are greatly underestimating the changes that occurred in COPY BINARY.
If the format difference had been as minor as you think, I would not
have gratuitously broken compatibility.

The real change that occurred here is that the individual data fields
go through per-datatype send/receive routines, which in addition to
implementing a mostly machine-independent binary format also provide
defenses against bad input data.

To continue to read the old COPY BINARY format, we'd have to bypass
those routines and allow direct read of the internal data formats.
This was a security risk before and would be a much bigger one now,
seeing that we allow COPY BINARY FROM STDIN to unprivileged users.  It
is trivial to crash the backend by feeding it bad internal-format data.

(I don't believe that the patch works anyway, given that you aren't doing
anything to disable use of the per-datatype receive routine.  It might
work as-is for text fields, and for integers on bigendian machines, but
not for much else.)

We are not going back to the pre-7.4 format.  Sorry.

            regards, tom lane

pgsql-hackers by date:

Previous
From: "D'Arcy J.M. Cain"
Date:
Subject: Re: python interface
Next
From: Joe Conway
Date:
Subject: cvs head compile failure