On 07.02.2011 14:17, Noah Misch wrote:
> Suppose you create several file_fdw foreign tables, query them together, and
> read(2) returns EIO for one of the files:
>
> [local] postgres=# SELECT * FROM ft0, ft1, ft2;
> ERROR: could not read from COPY file: Input/output error
>
> 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, but that strategy doesn't translate to twitter_fdw, firebird_fdw, etc. We
> need a convention for presenting foreign errors that clearly attributes them to
> the originating foreign table. What should it be?
>
> Perhaps something as simple as having the core foreign scan code push an error
> context callback that does errcontext("scan of foreign table \"%s\"", tabname)?
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.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
