On Thu, 2009-09-10 at 10:09 -0400, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > I am fuzzy on the implementation details for making COPY act as a data
> > source for INSERT/SELECT though. I had thought to make EXPLAIN a data
> > source, but it turned out not to be possible (as far as I could tell)
> > without making EXPLAIN a fully-reserved word, which you vetoed. It
> > seems likely that COPY will present similar issues, though I haven't
> > tried.
>
> IIRC the previous discussion touched on making it look like a
> set-returning function, although this would be a shade less convenient
> for option parsing etc.
>
> > I am also wondering what happens when someone embeds multiple COPY
> > statements in a single query
As long as they COPY from different input files it should be perfectly
OK. Though this already goes out into SQL/MED land.
> , or sticks one inside of a CTE or on the
> > inner side of a left join.
>
> Yeah, it would need to be restricted somehow. A straight SRF function
> would materialize its result, but I doubt we want that to happen for
> COPY.
Making SRF-s streamable is another thing that would make postgreSQL a
lot more powerful for all kinds of computing.
> (This brings up the whole question of performance impact, which would
> have to be thought about and minimized.)
Completely agree - nobody wants a slow COPY command.
> regards, tom lane
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability Services, Consulting and Training
