Re: logical changeset generation v6.8

Robert Haas escribió:

> There's that, too.  But again, these messages are not can't-happen
> scenarios.  The argument is just whether to reuse existing error
> message text (like "could not write file") or invent a new variation
> (like "could not write remapping file").  Andres' argument (which is
> valid) is that distinguished messages make it easier to troubleshoot
> without needing to turn on verbose error messages.  My argument (which
> I think is also valid) is that a user isn't likely to know what a
> remapping file is, and having more messages increases the translation
> burden.  Is there a project policy on this topic?

I would vote for a generic "could not write file %s" where the %s lets
the troubleshooter know the path of the file, and thus in what context
it is being read.  We already have a similar case where slru.c reports
error as pertaining to "transaction 12345" but the path is
"pg_subtrans/xyz" or multixact etc; while it doesn't explicitely say
what module is raising the error, it's pretty clear from the path.

Would that not work here?

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services