Re: COPY Transform support

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: COPY Transform support
Дата
Msg-id 188.1207273122@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: COPY Transform support  (Sam Mason <sam@samason.me.uk>)
Ответы Re: COPY Transform support  (Sam Mason <sam@samason.me.uk>)
Список 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 по дате отправления:

Предыдущее
От: Sam Mason
Дата:
Сообщение: Re: COPY Transform support
Следующее
От: "Pavan Deolasee"
Дата:
Сообщение: Re: [GENERAL] ANALYZE getting dead tuple count hopelessly wrong