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

From Robert Haas
Subject Re: WIP patch: add (PRE|POST)PROCESSOR options to COPY
Date
Msg-id CA+TgmobTvTvphRzDWeqA+SsGucrPnaOg9=Fj93JZLi-0an4ahQ@mail.gmail.com
Whole thread Raw
In response to Re: WIP patch: add (PRE|POST)PROCESSOR options to COPY  (Craig Ringer <craig@2ndQuadrant.com>)
Responses Re: WIP patch: add (PRE|POST)PROCESSOR options to COPY  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Nov 14, 2012 at 10:14 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
>> So?  You're already handing the keys to the kingdom to anybody who can
>> control the contents of that command line, even if it's only to point at
>> the wrong program.  And one man's "unexpected side-effect" is another
>> man's "essential feature", as in my examples above.
>
> That's true if they're controlling the whole command, not so much if
> they just provide a file name. I'm just worried that people will use it
> without thinking deeply about the consequences, just like they do with
> untrusted client input in SQL injection attacks.

Yeah.  If we're going to do this at all, and I'm not convinced it's
worth the work, I think it's definitely good to support a variant
where we specify exactly the things that will be passed to exec().
There's just too many ways to accidentally shoot yourself in the foot
otherwise.  If we want to have an option that lets people shoot
themselves in the foot, that's fine.  But I think we'd be smart not to
make that the only option.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Kohei KaiGai
Date:
Subject: Re: ALTER command reworks
Next
From: Peter Geoghegan
Date:
Subject: Re: tuplesort memory usage: grow_memtuples