Re: Better title output for psql \dt \di etc. commands - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Better title output for psql \dt \di etc. commands
Date
Msg-id 674707.1738698982@sss.pgh.pa.us
Whole thread Raw
In response to Re: Better title output for psql \dt \di etc. commands  (Álvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: Better title output for psql \dt \di etc. commands
List pgsql-hackers
=?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@alvh.no-ip.org> writes:
> On 2025-Feb-04, Tom Lane wrote:
>> =?utf-8?Q?=C3=81lvaro?= Herrera <alvherre@alvh.no-ip.org> writes:
>>> At this point I would just add a "translator:" comment that explains
>>> that the ??? bit is for unexpected cases and can be translated in the
>>> same way.

>> Hmm, do we have a standard policy or comment wording about that?
>> I looked for "translator: ... unexpected" and didn't find any
>> existing comments of that sort.

> I don't remember cases of messages of that kind marked for translation,
> so I'm not surprised that we don't have any such comments.  Those would
> typically be elog() or the errfoo_internal() cases, I think.

Yeah, that's what I would have thought.

The implementation I had in mind was to just invent a
pg_log_error_internal() macro alias for pg_log_error().
That'd take about two lines counting the explanatory comment.
This approach would fail to suppress the cost of gettext's
trying to look up the string, but surely we aren't concerned
about that here --- we just want to not burden translators
with the string.  (I need to check that gettext isn't smart
enough to see through a macro, though.  If it is, a static
inline function should do.)

            regards, tom lane



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: should we have a fast-path planning for OLTP starjoins?
Next
From: Robert Treat
Date:
Subject: Re: Eagerly scan all-visible pages to amortize aggressive vacuum