Re: COPY Transform support

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Sam Mason <sam(at)samason(dot)me(dot)uk>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: COPY Transform support
Date: 2008-04-04 01:38:42
Message-ID: 188.1207273122@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Sam Mason <sam(at)samason(dot)me(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavan Deolasee 2008-04-04 04:31:31 Re: [HACKERS] ANALYZE getting dead tuple count hopelessly wrong
Previous Message Sam Mason 2008-04-04 01:20:08 Re: COPY Transform support