Thread: pgsql: Improve wording of some pg_upgrade failure reports.
Improve wording of some pg_upgrade failure reports. Don't advocate dropping a whole table when dropping a column would serve. While at it, try to make the layout of these messages a bit cleaner and more consistent. Per suggestion from Daniel Gustafsson. No back-patch, as we generally don't like to churn translatable messages in released branches. Discussion: https://postgr.es/m/2798740.1619622555@sss.pgh.pa.us Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/c9c37ae03fea0c8ad467392ddf03940b61974935 Modified Files -------------- src/bin/pg_upgrade/check.c | 10 +++++----- src/bin/pg_upgrade/version.c | 26 ++++++++++++++------------ 2 files changed, 19 insertions(+), 17 deletions(-)
On 29.04.21 21:40, Tom Lane wrote:
> Improve wording of some pg_upgrade failure reports.
>
> Don't advocate dropping a whole table when dropping a column would
> serve. While at it, try to make the layout of these messages a
> bit cleaner and more consistent.
I don't understand how this makes the message layout cleaner. For example, this
@@ -456,10 +458,10 @@ old_11_check_for_sql_identifier_data_type_usage(ClusterInfo *cluster)
output_path))
{
pg_log(PG_REPORT, "fatal\n");
- pg_fatal("Your installation contains the \"sql_identifier\" data type in user tables\n"
- "and/or indexes. The on-disk format for this data type has changed, so this\n"
- "cluster cannot currently be upgraded. You can remove the problem tables or\n"
- "change the data type to \"name\" and restart the upgrade.\n"
+ pg_fatal("Your installation contains the \"sql_identifier\" data type in user tables.\n"
+ "The on-disk format for this data type has changed, so this\n"
+ "cluster cannot currently be upgraded. You can\n"
+ "drop the problem columns and restart the upgrade.\n"
"A list of the problem columns is in the file:\n"
" %s\n\n", output_path);
turns a message with uniform line length layout into a message with random line lengths.
What is the rationale behind this?
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> On 29.04.21 21:40, Tom Lane wrote:
>> Don't advocate dropping a whole table when dropping a column would
>> serve. While at it, try to make the layout of these messages a
>> bit cleaner and more consistent.
> I don't understand how this makes the message layout cleaner.
The main thing that's cleaner IMO is that it's separated what one
could call the primary error message ("Your installation contains FOO.")
from the errdetail, which formerly was run onto the same line in
some cases, but not others.
For translatability purposes, maybe we could consider how to split
those texts into separate message strings for each sentence? The
detail text is pretty nearly boilerplate and could be unified,
I suspect.
regards, tom lane