Re: Error attribution in foreign scans - Mailing list pgsql-hackers

From Itagaki Takahiro
Subject Re: Error attribution in foreign scans
Date
Msg-id AANLkTikn6XqjvnW+XsdV3m=Jry81Ye8XXGOKnZhAto52@mail.gmail.com
Whole thread Raw
In response to Re: Error attribution in foreign scans  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Error attribution in foreign scans  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Alex Hunsaker
Date:
Subject: Re: arrays as pl/perl input arguments [PATCH]
Next
From: Robert Haas
Date:
Subject: Re: Extensions versus pg_upgrade