From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Pavel Golub <pavel(at)microolap(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: raw output from copy |
Date: | 2015-07-27 11:28:53 |
Message-ID: | CAFj8pRC1Yj2W_u9rgm4tToenWx36RtxKRzitRtA_2bzP7EpaOA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2015-07-27 10:41 GMT+02:00 Heikki Linnakangas <hlinnaka(at)iki(dot)fi>:
> On 07/27/2015 06:55 AM, Craig Ringer wrote:
>
>> On 7 July 2015 at 14:32, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>>
>>> Hi
>>>
>>> previous patch was broken, and buggy
>>>
>>> Here is new version with fixed upload and more tests
>>>
>>
>> I routinely see people trying to use COPY ... FORMAT binary to export
>> a single binary field (like an image, for example) and getting
>> confused by the header PostgreSQL adds. Or using text-format COPY and
>> struggling with the hex escaping. It's clearly something people have
>> trouble with.
>>
>> It doesn't help that while lo_import and lo_export can read paths
>> outside the datadir (and refuse to read from within it),
>> pg_read_binary_file is superuser only and disallows absolute paths.
>> There's no corresponding pg_write_binary_file. So users who want to
>> import and export a single binary field tend to try to use COPY. We
>> have functionality for large objects that has no equivalent for
>> 'bytea'.
>>
>> I don't love the use of COPY for this, but it gets us support for
>> arbitrary clients pretty easily. Otherwise it'd be server-side only
>> via local filesystem access, or require special psql-specific
>> functionality like we have for lo_import etc.
>>
>
> COPY seems like a strange interface for this. I can see the point that the
> syntax is almost there already, for both input and output. But even that's
> not quite there yet, we'd need the new RAW format. And as an input method,
> COPY is a bit awkward, because you cannot easily pass the file to a
> function, for example. I think this should be implemented in psql, along
> the lines of Andrew's original \bcopy patch.
>
> There are a couple of related psql-features here actually, that would be
> useful on their own. The first is being able to send the query result to a
> file, for a single query only. You can currently do:
>
> \o /tmp/foo
> SELECT ...;
> \o
>
> But more often than not, when I try to do that, I forget to do the last
> \o, and run another query, and the output still goes to the file. So it'd
> be nice to have a \o option that only affects the next query. Something
> like:
>
> \O /tmp/foo
> SELECT ...;
>
> The second feature needed is to write the output without any headers, row
> delimiters and such. Just the datum. And the third feature is to write it
> in binary. Perhaps something like:
>
> \O /tmp/foo binary
> SELECT blob FROM foo WHERE id = 10;
>
> What about input? This is a whole new feature, but it would be nice to be
> able to pass the file contents as a query parameter. Something like:
>
> \P /tmp/foo binary
> INSERT INTO foo VALUES (?);
>
The example of input is strong reason, why don't do it via inserts. Only
parsing some special "?" symbol needs lot of new code.
In this case, I don't see any advantage of psql based solution. COPY is
standard interface for input/output from/to files, and it should be used
there.
Regards
Pavel
>
>
> - Heikki
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Korotkov | 2015-07-27 12:04:38 | Re: Proposal for CSN based snapshots |
Previous Message | Ildus Kurbangaliev | 2015-07-27 10:20:03 | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |