Re: COPY Transform support

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: COPY Transform support
Date: 2008-04-03 21:51:28
Message-ID: 47F55160.402@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>
>> AFAIK the state of the art is actually to load the data into a table which
>> closely matches the source material, sometimes just columns of text. Then copy
>> it all to another table doing transformations. Not impressed.
>>
>
> 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.
>
>
>

Several years ago Bruce and I discussed the then theoretical use of a
SELECT query as the source for COPY TO, and we agreed that the sane
analog would be to have an INSERT query as the target of COPY FROM.

This idea seems to take that rather further. If doable I think it would
be cool, as long as people don't try using it as an alternative storage
engine. I can just imagine people creating views over such SELECT
statements ...

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-04-03 21:59:04 Re: Row estimation for "var <> const" and for "NOT (...)" queries
Previous Message Svenne Krap 2008-04-03 21:39:30 Re: [GENERAL] SHA1 on postgres 8.3