Re: R: feature proposal ...
От | Hans-Jürgen Schönig |
---|---|
Тема | Re: R: feature proposal ... |
Дата | |
Msg-id | 43316851.7070805@cybertec.at обсуждение исходный текст |
Ответ на | R: feature proposal ... ("Paolo Magnoli" <pmagnoli@systemevolution.it>) |
Ответы |
Re: R: feature proposal ...
(Tom Lane <tgl@sss.pgh.pa.us>)
Re: R: feature proposal ... ("Joshua D. Drake" <jd@commandprompt.com>) Re: R: feature proposal ... ("Cristian Prieto" <cristian@clickdiario.com>) |
Список | pgsql-hackers |
no because a new is not a heap ... em=# create view x as select * from pg_class; CREATE VIEW em=# copy x to '/tmp/x'; ERROR: cannot copy from view "x" best regards, hans Paolo Magnoli wrote: > Can't you just use a view? > > -----Messaggio originale----- > Da: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org]Per conto di Hans-Jürgen > Schönig > Inviato: mercoledì 21 settembre 2005 15.30 > A: pgsql-hackers@postgresql.org; eg@cybertec.at > Oggetto: [HACKERS] feature proposal ... > > > hackers, > > currently we have to hack tons of export scripts for various customers. > the problem is: if tables can be exported straight forward COPY will > give you all you need but when data has to be transformed while > exporting things start becoming a bit more complex. usually people want > to have CSV file (excel-ify data) which is supported by COPY. > > the problem is: COPY can write data returned by a SELECT statement to a > file. our idea is to implement precisely that. > > example: > > COPY TO file_name USING some_select_statement; > > the advantage would be that COPY would then be able to export data and > transform it on the fly. this would save many people a lot of work > because complex data extractors could in many cases be replaced by > simple SQL scripts. > > how we plan to implement that: > currently copy simply opens a table and loops through the tuples (see > command/copy.c starting at line 1115). > to implement the desired feature we just had to add some SPI code to the > scenery (SPI will also return HeapTuples so it should fit in there). > > Any comments? > > Best regards, > > Hans > > > -- > Cybertec Geschwinde & Schönig GmbH > Schöngrabern 134; A-2020 Hollabrunn > Tel: +43/1/205 10 35 / 340 > www.postgresql.at, www.cybertec.at > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend > -- Cybertec Geschwinde & Schönig GmbH Schöngrabern 134; A-2020 Hollabrunn Tel: +43/1/205 10 35 / 340 www.postgresql.at, www.cybertec.at
В списке pgsql-hackers по дате отправления: