Re: WIP patch: add (PRE|POST)PROCESSOR options to COPY
От | Andrew Dunstan |
---|---|
Тема | Re: WIP patch: add (PRE|POST)PROCESSOR options to COPY |
Дата | |
Msg-id | 50A3D25B.7070008@dunslane.net обсуждение исходный текст |
Ответ на | Re: WIP patch: add (PRE|POST)PROCESSOR options to COPY (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 11/14/2012 11:56 AM, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> On 11/14/2012 11:39 AM, Tom Lane wrote: >>> What happened to the previous proposal of treating the COPY >>> target as a pipe specification, ie >> I'd like to be able to filter STDIN if possible - with this syntax how >> is COPY going to know to hook up STDIN to the program? > Huh? That's fairly nonsensical for the backend-side case; there's no > way that stdin (or stdout) of a backend is going to connect anywhere > useful for this purpose. As for doing it on the psql side (\copy), > I think it would be more or less automatic. If you do say > > foo | psql -c "\copy tab from 'bar |'" dbname > > then bar is going to inherit psql's stdin, which is coming from foo. > > Why does it make less sense on the backend than COPY foo FROM STDIN ? Why shouldn't I want to be able to filter or transform the input? I have a client with a pretty complex backend-driven ETL tool. One of the annoying things about it is that we have to transfer the file to the backend before we can process it. I can imagine this leading to a similar annoyance. cheers andrew
В списке pgsql-hackers по дате отправления: