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


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 по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: raw output from copy
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: psql stops completion for the only matching schema name.