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

From Andrew Dunstan
Subject Re: raw output from copy
Date
Msg-id 56FADD0F.8060808@dunslane.net
Whole thread Raw
In response to Re: raw output from copy  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: raw output from copy  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: raw output from copy  ("Daniel Verite" <daniel@manitou-mail.org>)
List 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 by date:

Previous
From: Paul Ramsey
Date:
Subject: Re: Parallel Queries and PostGIS
Next
From: Petr Jelinek
Date:
Subject: Re: Sequence Access Method WIP