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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
