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

From Tom Lane
Subject Re: WIP patch: add (PRE|POST)PROCESSOR options to COPY
Date
Msg-id 20767.1353008153@sss.pgh.pa.us
Whole thread Raw
In response to Re: WIP patch: add (PRE|POST)PROCESSOR options to COPY  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: WIP patch: add (PRE|POST)PROCESSOR options to COPY
Re: WIP patch: add (PRE|POST)PROCESSOR options to COPY
Re: WIP patch: add (PRE|POST)PROCESSOR options to COPY
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> 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.

[ shrug... ]  Once again, that will turn this from a ten-line patch
into hundreds of lines (and some more, different, hundreds of lines
for Windows I bet), with a corresponding growth in the opportunities
for bugs, for a benefit that's at best debatable.

The biggest problem this patch has had from the very beginning is
overdesign, and this is more of the same.  Let's please just define the
feature as "popen, not fopen, the given string" and have done.  You can
put all the warning verbiage you want in the documentation.  (But note
that the server-side version would be superuser-only in any flavor of
the feature.)
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_ctl reload -o "...."
Next
From: Peter Geoghegan
Date:
Subject: Re: tuplesort memory usage: grow_memtuples