Re: Re: COPY BINARY file format proposal

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: COPY BINARY file format proposal
Date: 2000-12-08 07:31:05
Message-ID: 29751.976260665@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> Next 4 bytes: integer layout field. This consists of the int32 constant
> 0x0A820D0A expressed in the source machine's endianness. (Again, value
> chosen with malice aforethought, to catch files munged by things like
> DOS/Unix newline conversion or high-bit-stripping.)

Actually, that won't do. A little-endian machine would write 0A 0D 82
0A which would fail to trigger newline converters that are looking for
\r followed by \n (0D 0A). If we're going to take seriously the idea of
detecting newline transforms, then we need to incorporate the test
pattern into the fixed-byte-order signature.

How about:

Signature: 12-byte sequence "PGBCOPY\n\377\r\n\0" (detects newline
replacements, dropped nulls, dropped high bits, parity changes);

Integer layout field: int32 constant 0x01020304 in source's byte order.

The rest as before.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Nosenko 2000-12-08 07:33:46 Re: Oracle-compatible lpad/rpad behavior
Previous Message Philip Warner 2000-12-08 07:15:30 Re: Re: COPY BINARY file format proposal