Re: raw output from copy

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: raw output from copy
Дата
Msg-id 56FADD0F.8060808@dunslane.net
обсуждение исходный текст
Ответ на Re: raw output from copy  (Pavel Stehule <pavel.stehule@gmail.com>)
Ответы Re: raw output from copy  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: raw output from copy  ("Daniel Verite" <daniel@manitou-mail.org>)
Список pgsql-hackers

On 03/28/2016 11:18 PM, Pavel Stehule wrote:
>
>
>
>         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.
>
>


The I would suggest we try to invent something for psql which does help 
with it. I just don't see this as an SQL problem. Pretty much any driver 
library will have no difficulty in handling binary input and output. 
It's only psql that has an issue, ISTM, and therefore I believe that's 
where the fix should go. What else is going to use this? As an SQL 
change this seems like a solution in search of a problem. If someone can 
make a good case that this is going to be of general use I'll happily go 
along, but I haven't seen one so far.

cheers

andrdew



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

Предыдущее
От: Paul Ramsey
Дата:
Сообщение: Re: Parallel Queries and PostGIS
Следующее
От: Petr Jelinek
Дата:
Сообщение: Re: Sequence Access Method WIP