Re: raw output from copy

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: raw output from copy
Дата
Msg-id CAFj8pRDf5Ou3dnQc2nhTD=rqFPhB0XfBNtEqskrfDBGFQqy_mA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: raw output from copy  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: raw output from copy  (Simon Riggs <simon@2ndQuadrant.com>)
Re: raw output from copy  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers


2015-07-02 16:02 GMT+02:00 Andrew Dunstan <andrew@dunslane.net>:

On 07/02/2015 09:43 AM, Simon Riggs wrote:
On 2 July 2015 at 14:02, Andrew Dunstan <andrew@dunslane.net <mailto:andrew@dunslane.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.
 

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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: drop/truncate table sucks for large values of shared buffers
Следующее
От: Petr Jelinek
Дата:
Сообщение: Re: [BUGS] BUG #13126: table constraint loses its comment