Re: raw output from copy

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(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:40:45
Message-ID: 55954D6D.5040608@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 07/02/2015 10:07 AM, Pavel Stehule wrote:
>
>
> 2015-07-02 16:02 GMT+02:00 Andrew Dunstan <andrew(at)dunslane(dot)net
> <mailto:andrew(at)dunslane(dot)net>>:
>
>
> 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> <mailto: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.
>
>
> It can be used from psql without any problems.

In fact your patch will not work with psql's \copy nor to stdout at all,
unless I'm misreading it:

- if (cstate->binary)
+ if (cstate->binary || cstate->raw)
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("COPY BINARY is not supported to stdout or from
stdin")));

So it looks like you're only supporting this where the server is writing
to a file. That's horribly narrow, and certainly doesn't meet my
original need.

Does the COPY line protocol even support binary data? If not, we're dead
in the water here from the psql POV. Because my patch doesn't use the
COPY protocol it doesn't have this problem.

Perhaps we should do both, although I'm not sure I understand the use
case for the COPY solution.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2015-07-02 15:02:19 Re: raw output from copy
Previous Message Tom Lane 2015-07-02 14:29:38 Re: [PROPOSAL] VACUUM Progress Checker.