On Wed, Feb 09, 2011 at 10:55:05AM +0900, Itagaki Takahiro wrote:
> 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.
Comprehensively hiding the name from non-superusers is ideal, but it seems
adequate to document that the name will not be kept secret. The superuser could
always mask the name by creating a symbolic link in $PGDATA and referencing that
in the foreign table configuration.
> 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.
This would be good to get right by 9.1 (not sure what "right" is, though).