Re: Ragged CSV import

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