Re: raw output from copy
| От | Pavel Stehule |
|---|---|
| Тема | Re: raw output from copy |
| Дата | |
| Msg-id | CAFj8pRBK8p33tx3annck6Cm3VqOXyNJ92oJhENefrqYBqAitpw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: raw output from copy (Pavel Stehule <pavel.stehule@gmail.com>) |
| Список | pgsql-hackers |
Hi
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.
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.
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
RegardsPavel
cheers
andrew
В списке pgsql-hackers по дате отправления: