Re: Ragged CSV import

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Ragged CSV import
Date: 2009-09-10 14:09:23
Message-ID: 23048.1252591763@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)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, 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.

(This brings up the whole question of performance impact, which would
have to be thought about and minimized.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-09-10 14:11:14 Re: Ragged CSV import
Previous Message Kevin Grittner 2009-09-10 14:06:55 Re: RfD: more powerful "any" types