Re: raw output from copy - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: raw output from copy
Date
Msg-id CAFj8pRBK8p33tx3annck6Cm3VqOXyNJ92oJhENefrqYBqAitpw@mail.gmail.com
Whole thread Raw
In response to Re: raw output from copy  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
Hi


Anyway this is certainly not committable as-is, so I'm setting it back
to Waiting on Author.  But the fact that both libpq and ecpg would need
updates makes me question whether we can safely pretend that this isn't
a protocol break.

                       


In that case I humbly submit that there is a case for reviving the psql patch I posted that kicked off this whole thing and lets you export a piece of binary data from psql quite easily. It should certainly not involve any protocol break.

The psql only solution can work only for output. Doesn't help with input.

In this case, I am thinking so the features of COPY statement is perfect for this feature. The way from a  content to the file is direct. In psql you have to off - tuple separator, record separator, you have to set output file. You can get same effect, but with more work. In previous version it was relatively  hard to use it from command line - now, with multi command -c is much simpler, but still the COPY is the ideal.

I agree, so output formats of psql is nice feature. And should be pretty nice, if we support more common formats - like csv, simple xml, simple json. I believe so sometime the redundancy is acceptable, if the cost is not too high.

sorry for offtopic - I would to see some output format on client side, but the format possibilities are on server side. So there are natural idea - define server side output format. psql output format just can wrap it.

Regards

Pavel


Regards

Pavel
 

cheers

andrew


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: raw output from copy
Next
From: Kyotaro HORIGUCHI
Date:
Subject: psql stops completion for the only matching schema name.