Re: COPY Transform support - Mailing list pgsql-hackers

From Tom Lane
Subject Re: COPY Transform support
Date
Msg-id 188.1207273122@sss.pgh.pa.us
Whole thread Raw
In response to Re: COPY Transform support  (Sam Mason <sam@samason.me.uk>)
Responses Re: COPY Transform support  (Sam Mason <sam@samason.me.uk>)
List pgsql-hackers
Sam Mason <sam@samason.me.uk> writes:
> On Thu, Apr 03, 2008 at 03:57:38PM -0400, Tom Lane wrote:
>> I liked the idea of allowing COPY FROM to act as a table source in a
>> larger SELECT or INSERT...SELECT.  Not at all sure what would be
>> involved to implement that, but it seems a lot more flexible than
>> any other approach.

> I'm not sure why new syntax is needed, what's wrong with having a simple
> set of procedures like:
>  readtsv(filename TEXT) AS SETOF RECORD

Yeah, I was thinking about that too.  The main stumbling block is that
you need to somehow expose all of COPY's options for parsing an input
line (CSV vs default mode, quote and delimiter characters, etc).
It's surely doable but it might be pretty ugly compared to bespoke
syntax.

Another thing is that nodeFunctionScan.c is not really designed for
enormous function result sets --- it dumps the results into a tuplestore
whether that's needed or not.  This is a performance bug that we ought
to address anyway, but we'd really have to fix it if we want to approach
the COPY problem this way.  Just sayin'.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Sam Mason
Date:
Subject: Re: COPY Transform support
Next
From: "Pavan Deolasee"
Date:
Subject: Re: [GENERAL] ANALYZE getting dead tuple count hopelessly wrong