Karl O. Pinc wrote:
>
> On 04/19/2007 09:39:18 AM, Alvaro Herrera wrote:
>
> >
> >I'm not sure the plan is OK as stated. You wouldn't want to force to
> >parse the query again for each row. Rather, create a prepared
> >statement
> >(already parsed, because you obtain it from the parsetree stored in
> >the
> >INSERT rule) to pass to the executor.
>
> I wasn't going to parse and plan an INSERT for each row
> of data to COPY. Step 7 is the step that iterates over
> the rows of COPY data. I make my own PREPAREd insert
> and execute it in step 7 for each row of COPY data.
>
> It seems to me it'd be eaiser to write my own INSERT statement
> and call raw_parser on it than to try to modify the parsed
> INSERT statement stored in the INSERT rule. (I didn't know
> that was even there.)
Based on past records, I would guess that that approach would be
rejected or at least frowned upon. It happened to the COPY (query) TO
patch.
> This is because the COPY statement could only insert into some columns
> of the view.
Then you would fill the missing values with DEFAULT or NULL expressions.
> It just seems easier to me to write an INSERT statement
> and parse it than to take stuff out of an already
> existing raw parse tree. Am I wrong?
Well, if it's easier for you to do it, go ahead; but if you want the
patch accepted that's a whole'nother matter. I wrote several easy
patches that were rejected.
Maybe the easy patch serves as proof of concept to make sure it all
works, which you then rework to do things properly. We don't care _how_
you arrived at a patch, if it's good.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.