On Wed, Feb 09, 2011 at 10:55:05AM +0900, Itagaki Takahiro wrote: > 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.
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). -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
