Re: raw output from copy - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: raw output from copy
Date
Msg-id CAFj8pRBRke7Rak7LQhVLQ-4F5aA0gWhMQLycf2FFbW3w5pjqUw@mail.gmail.com
Whole thread Raw
In response to Re: raw output from copy  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: raw output from copy
Re: raw output from copy
List pgsql-hackers
Hi

previous patch was broken, and buggy

Here is new version with fixed upload and more tests

The interesting is so I should not to modify interface or client - so it should to work with any current driver with protocol support >= 3.

Regards

Pavel



2015-07-06 23:34 GMT+02:00 Pavel Stehule <pavel.stehule@gmail.com>:
Hi

here is a version with both direction support.

postgres=# copy foo from '/tmp/1.jpg' (format raw);
COPY 1
Time: 93.021 ms
postgres=# \dt+ foo
                   List of relations
┌────────┬──────┬───────┬───────┬────────┬─────────────┐
│ Schema │ Name │ Type  │ Owner │  Size  │ Description │
╞════════╪══════╪═══════╪═══════╪════════╪═════════════╡
│ public │ foo  │ table │ pavel │ 256 kB │             │
└────────┴──────┴───────┴───────┴────────┴─────────────┘
(1 row)

postgres=# \copy foo to '~/3.jpg' (format raw)
COPY 1
Time: 2.401 ms


Regards

Pavel

2015-07-02 17:02 GMT+02:00 Tom Lane <tgl@sss.pgh.pa.us>:
Andrew Dunstan <andrew@dunslane.net> writes:
> Does the COPY line protocol even support binary data?

The protocol, per se, just transmits a byte stream.  There is a field
in the CopyInResponse/CopyOutResponse messages that indicates whether
a text or binary copy is being done.  One thing we'd have to consider
is whether "raw" mode is sufficiently different from binary to justify
an additional value for this field, and if so whether that constitutes
a protocol break.

IIRC, psql wouldn't really care; it just transfers the byte stream to or
from the target file, regardless of text or binary mode.  But there might
be other client libraries that are smarter and expect "binary" mode to
mean the binary file format specified in the COPY reference page.  So
there may be value in being explicit about "raw" mode in these messages.

A key point in all this is that people who need "raw" transfer probably
need it in both directions, a point that your SELECT proposal cannot
satisfy, but hacking COPY could.  So I lean towards the latter really.

                        regards, tom lane


Attachment

pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Parallel Seq Scan
Next
From: Jeevan Chalke
Date:
Subject: Re: [PATCH] two-arg current_setting() with fallback