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
- Re: [HACKERS] Re: COPY BINARY file format proposal Philip Warner
- Re: [HACKERS] Re: COPY BINARY file format proposal Tom Lane
- Re: [HACKERS] Re: COPY BINARY file format propo... Philip Warner
- Re: [HACKERS] Re: COPY BINARY file format p... Tom Lane
- Re: [HACKERS] Re: COPY BINARY file form... Philip Warner
- Re: [HACKERS] Re: COPY BINARY file... Tom Lane
- Re: [HACKERS] Re: COPY BINARY file... Philip Warner
- Re: [HACKERS] Re: COPY BINARY file... Tom Lane
- Re: [HACKERS] Re: COPY BINARY file... Bruce Momjian
- Re: [HACKERS] Re: COPY BINARY file... Philip Warner
- Re: [HACKERS] Re: COPY BINARY file... Tom Lane
- Re: [HACKERS] Re: COPY BINARY file... Philip Warner
- Re: [HACKERS] Re: COPY BINARY file... Tom Lane
- Re: [HACKERS] Re: COPY BINARY file... Philip Warner
- Re: [HACKERS] Re: COPY BINARY file... Tom Lane
- Re: [HACKERS] Re: COPY BINARY file... Peter Eisentraut
- Re: [HACKERS] Re: COPY BINARY file... Nathan Myers
- Re: [HACKERS] Re: COPY BINARY file... Ross J. Reedstrom
- Re: [HACKERS] Re: COPY BINARY file... Tom Lane
- Re: [HACKERS] Re: COPY BINARY file... Bruce Momjian
- Re: [HACKERS] Re: COPY BINARY file... Nathan Myers