Re: [HACKERS] Performance testing of COPY (SELECT) TO

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > My question is, if we allow this:
> > copy (select * from view) to stdout;
> > (or to a file, whatever), is it enough for you? Or would you insist on
> > also having
> > copy view to stdout;
> > ?
>
> > We can, and the posted patch does, support the first form, but not the
> > second. In fact I deliberately removed support for the second form for
> > Zoltán's patch because it uglifies the surrounding code.
>
> Personally, I have no moral objection to supporting the second form
> as a special case of the general COPY-from-select feature, but if it
> can't be done without uglifying the code then I'd agree with dropping
> it. I guess the question is whether the uglification is intrinsic or
> just a result of being descended from a poor original implementation.

I'm quite sure you could refactor things as needed to support the "COPY
view" case reasonably. It's just beyond what I'd do during the current
freeze.

It seems I'm alone on the "view may be slow" camp. If I lost that
argument I have no problem accepting that.

> The feature-freeze argument seems not relevant, given that the code
> we had on the feature-freeze date did both things.

Actually IIRC the patch on the queue only did the "COPY view" stuff, not
the COPY select. (Thanks go to Zoltan for properly morphing the patch).

> Has this patch settled to the point where I can review it, or is it
> still in motion?

Personally I'm finished doing the cleanup I wanted to do.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.