From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Nisha Moond <nisha(dot)moond412(at)gmail(dot)com> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, Peter Smith <smithpb2250(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Improve the connection failure error messages |
Date: | 2024-07-08 19:30:20 |
Message-ID: | 1184471.1720467020@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Nisha Moond <nisha(dot)moond412(at)gmail(dot)com> writes:
> Attached v5 patch with the translator comments as suggested.
I looked at this, and I agree with the goal, but I find just about all
of the translator comments unnecessary. The ones that are useful are
useful only because the message is violating one of our message style
guidelines [1]:
When citing the name of an object, state what kind of object it is.
Rationale: Otherwise no one will know what “foo.bar.baz” refers to.
So, for example, where you have
+
+ /*
+ * translator: first %s is the subscription name, second %s is the
+ * error
+ */
+ errmsg("subscription \"%s\" could not connect to the publisher: %s", stmt->subname, err)));
I don't find that that translator comment is adding anything.
But there are a couple of places like
+ /*
+ * translator: first %s is the slotsync worker name, second %s is the
+ * error
+ */
+ errmsg("\"%s\" could not connect to the primary server: %s", app_name.data, err));
I think that the right cure for the ambiguity here is not to add a
translator comment, but to label the name properly, perhaps like
errmsg("synchronization worker \"%s\" could not connect to the primary server: %s",
app_name.data, err));
regards, tom lane
[1] https://www.postgresql.org/docs/devel/error-style-guide.html#ERROR-STYLE-GUIDE-OBJECT-TYPE
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2024-07-08 19:37:49 | Re: Add a GUC check hook to ensure summarize_wal cannot be enabled when wal_level is minimal |
Previous Message | Nathan Bossart | 2024-07-08 19:29:16 | Re: allow changing autovacuum_max_workers without restarting |