From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Pavel Golub <pavel(at)microolap(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: raw output from copy |
Date: | 2015-07-02 14:02:52 |
Message-ID: | 5595448C.7050802@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 07/02/2015 09:43 AM, Simon Riggs wrote:
> On 2 July 2015 at 14:02, Andrew Dunstan <andrew(at)dunslane(dot)net
> <mailto:andrew(at)dunslane(dot)net>> wrote:
>
>
> Please don't top-post on the PostgreSQL lists. You've been around
> here long enough to know that bottom posting is our custom.
>
> I posted a patch for this in 2013 at
> <http://www.postgresql.org/message-id/50F2FA92.9040000@dunslane.net>
> but it can apply to a SELECT, and doesn't need COPY. Nobody seemed
> very interested, so I dropped it. Apparently people now want
> something along these lines, which is good.
>
>
> It's a shame that both solutions are restricted to either COPY or psql.
>
> Both of those are working on suggestions from Tom, so there is no
> history of preference there.
>
> Can we have both please, gentlemen?
>
> If we implemented Andrew's solution, how would we request it in a COPY
> statement? Seems like we would want the RAW format keyword anyway.
>
>
What's the use case? My original motivation was that I had a function
that returned a bytea (it was a PDF in fact) that I wanted to be able to
write to a file. Of course, this is easy enough to do with a client
library like perl's DBD::Pg, but it seems sad to have to resort to that
for something so simple.
My original suggestion
(<http://www.postgresql.org/message-id/4EA1B83B.2050605@pgexperts.com>)
was to invent a \bcopy command.
I don't have a problem in building in a RAW mode for copy, but we'll
still need to teach psql how to deal with it.
Another case where it could be useful is JSON - so we can avoid having
to play tricks like
<http://adpgtech.blogspot.com/2014/09/importing-json-data.html>. Similar
considerations probably apply to XML, and the tricks are less guaranteed
to work.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-07-02 14:03:33 | Re: drop/truncate table sucks for large values of shared buffers |
Previous Message | Pavel Stehule | 2015-07-02 14:01:46 | Re: raw output from copy |