Andreas Pflug <[EMAIL PROTECTED]> writes: > The attached patch implements COPY ... WITH [BINARY] COMPRESSION > (compression implies BINARY). The copy data uses bit 17 of the flag > field to identify compressed data.
I think this is a pretty horrid idea, because it changes pg_lzcompress from an unimportant implementation detail into a backup file format that we have to support till the end of time. What happens if, say, we need to abandon pg_lzcompress because we find out it has patent problems? It *might* be tolerable if we used gzip instead, but I really don't see the argument for doing this inside the server at all: piping to gzip seems like a perfectly acceptable solution, quite possibly with higher performance than doing it all in a single process (which isn't going to be able to use more than one CPU). I don't see the argument for restricting it to binary only, either. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly