On Mon, Feb 7, 2011 at 22:47, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> On Mon, Feb 7, 2011 at 21:17, Noah Misch <noah@leadboat.com> wrote:
>> The message does not show which foreign table yielded the error. We could evade
>> the problem in this case by adding a file name to the error message in the COPY
>> code,
> Yeah, an error context callback like that makes sense. In the case of the
> file FDW, though, just including the filename in the error message seems
> even better. Especially if the error is directly related to failure in
> reading the file.
What do you think about filenames in terms of security? We will allow
non-superusers to use existing foreign tables of file_fdw.
For reference, we hide some path settings in GUC variables.
We also reconsider privilege of fdwoptions, umoptions, etc. They could
contain password or server-side path, but all users can retrieve the
values. It's an existing issue, but will be more serious in 9.1.
--
Itagaki Takahiro