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

Alvaro Herrera írta:
> Zoltan Boszormenyi wrote:
>
>> Alvaro Herrera írta:
>>
>
>
>> But COPY view (col1, col2, ...) TO may still be
>> useful even if the COPY (SELECT ...) (col1, col2, ...) TO
>> is pointless. [1]
>>
>
> Hum, I don't understand what you're saying here -- are you saying that
> you can't do something with the first form, that you cannot do with the
> second?
>

Say you have a large often used query.
Would you like to retype it every time
or just create a view? Later you may want to
export only a subset of the fields...

My v8 had the syntax support for

COPY (SELECT ...) (col1, col2, ...) TO
and it was actually working. In your v9
you rewrote the syntax parsing so that
feature was lost in translation.

>>> It's ugly because you are forcing the system to parse something that
>>> was already parsed.
>>>
>> Well, to be true to the word, during parsing COPY view TO
>> the parser never saw SELECT * FROM view.
>>
>
> Hmm!
>
> The COPY view stuff stopped working when I changed back the "relation"
> case. Your patch changed it so that instead of flowing as RangeVar all
> the way to the copy.c code, the parser changed it into a "select * from
> %s" query, and then stashed the resulting Query node into the "query"
> %case. (So what was happening was that the Relation case was never
> %used). I reverted this.
>

Well, the VIEW case wasn't supported before
so I took the opportunity to transform it in
analyze.c which you deleted as being ugly.

>>> On the other hand I don't see why you are arguing in favor of a useless
>>> feature whose coding is dubious; you can have _the same thing_ with nice
>>> code and no discussion.
>>>
>> Because of [1] and because Mr. Schoenig's arguments
>> about changing schemas.
>>
>
> Yeah, that argument makes sense to me as well.
>

So, may I put it back? :-)
Also, can you suggest anything cleaner than
calling raw_parser("SELECT * FROM view")?