On Mon, Feb 7, 2011 at 22:47, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > On Mon, Feb 7, 2011 at 21:17, Noah Misch <n...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
