Re: raw output from copy

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

In response to

Responses

Browse pgsql-hackers by date

  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