Re: WIP patch: add (PRE|POST)PROCESSOR options to COPY - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: WIP patch: add (PRE|POST)PROCESSOR options to COPY
Date
Msg-id CAHGQGwGx75+9+EMaQERXsdanrXFJq3JB6vCMkDsJxY=0aCQ8Lw@mail.gmail.com
Whole thread Raw
In response to Re: WIP patch: add (PRE|POST)PROCESSOR options to COPY  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Thu, Nov 15, 2012 at 12:31 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 14 November 2012 15:09, Fujii Masao <masao.fujii@gmail.com> wrote:
>
>>> Here, progname for COPY IN is the user-supplied program that takes filename as
>>> its argument and that writes on standard output.
>>
>> What about further extending the COPY IN syntax to the following?
>>
>>     COPY table_name FROM 'progname [ option, ... ]' WITH ...
>>
>> I'd just like to execute
>>
>>     COPY vmstat_table FROM 'vmstat' WITH ...
>
> I think we should be using FDWs/SRFs here, not inventing new
> syntax/architectures for executing external code, so -1 from me.
>
> We can already do
> INSERT table SELECT * FROM fdw;
> with any logic for generating data lives inside an FDW or SRF.
>
> If we want it in COPY we can have syntax like this...
> COPY table FROM (SELECT * FROM fdw)

New syntax looks attractive to me because it's easy to use that.
It's not easy to implement the FDW for the external program which
a user wants to execute.

Of course if someone implements something like any_external_program_fdw,
I would change my mind..

Regards,

-- 
Fujii Masao



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: [PATCH] Patch to compute Max LSN of Data Pages
Next
From: Alvaro Herrera
Date:
Subject: Re: WIP patch: add (PRE|POST)PROCESSOR options to COPY