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
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 |