Re: raw output from copy

On Sat, Feb 27, 2016 at 2:26 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
wrote:

> Hi
>
> 2015-08-06 10:37 GMT+02:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
>
>> Hi,
>>
>> Psql based implementation needs new infrastructure (more than few lines)
>>
>> Missing:
>>
>> * binary mode support
>> * parametrized query support,
>>
>> I am not against, but both points I proposed, and both was rejected.
>>
>> So why dont use current infrastructure? Raw copy is trivial patch.
>>
>
> I was asked by Daniel Verite about reopening this patch in opened
> commitfest.
>
> I am sending rebased patch
>
> Regards
>
> Pavel
>
>
>
Since this patch does something I need for my own work, I've signed up as a
reviewer.

From a design standpoint, I feel that COPY is the preferred means of
dealing with data from sources too transient to justify setting up a
foreign data wrapper, and too simple to justify writing application code.
So, for me, RAW is the right solution, or at least *a* right solution.

My first pass of reading the code changes and the regression tests is
complete, and I found the changes to be clear and fairly straightforward.
This shouldn't surprise anyone, as the previous reviewers had only minor
quibbles with the code. So far, so good.

The regression tests seem to adequately cover all new functionality, though
I wonder if we should add some cases that highlight situations where BINARY
mode is insufficient.

Before I give my approval, I want to read it again more closely to make
sure that no cases were skipped with regard to the (binary || raw) and
(binary || !raw) tests. Also, I want to use it on some of my problematic
files. Maybe I'll find a good edge case. Probably not.

I hope to find time for those things in the next few days.