Re: Improve the connection failure error messages

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

In response to

Responses

Browse pgsql-hackers by date

  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