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 opinion is same - there all necessary infrastructure is ready and when we work with IO, then we use COPY natively. I hope so main use case (export bytea) is solved, but there are a possibility to enhance this command by COPY options - what is, I am thinking, a advantage of this way.
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.
