Re: Simplify code building the LR conflict messages

From: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
To: Peter Smith <smithpb2250(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Simplify code building the LR conflict messages
Date: 2025-11-28 13:08:33
Message-ID: 202511281006.5rgwjxvqlnpj@alvherre.pgsql
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello,

So, what we're doing here is to append further row-identifying details
to an errdetail string that already contains some explanation of the
problem. That is, we have something like

DETAIL: The row to be updated was deleted.

and then we add whatever this function produces, after a newline. I
don't remember any other place in our code that does such a thing. The
result would look something like

DETAIL: The row to be updated was deleted.
Key: (1, 2); remote row (1,2,3); replica identity full (1,2,3).

or something like that, where each of the parts can begin with uppercase
or not, with a semicolon or not, depending on whether there are any
previous parts.

I wonder if it would make more sense to move this identifying
information to a CONTEXT line instead, where we won't have to care about
the uppercase.

We still have to worry about the semicolon though. Maybe we should make
that explicit in the string but given control to the translator by doing
something like

/* translator: first %s is either empty or a translated list
separator, second %s is a row descriptor */
appendStringInfo(&buf, "%sremote row %s", empty ? "" :
/* translator: this is used as a list separator */
_("; "), remote_row_description);

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"Debido a que la velocidad de la luz es mucho mayor que la del sonido,
algunas personas nos parecen brillantes un minuto antes
de escuchar las pelotudeces que dicen." (Roberto Fontanarrosa)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2025-11-28 13:10:53 Re: headerscheck ccache support
Previous Message Ashutosh Bapat 2025-11-28 13:05:44 Re: POC: make mxidoff 64 bits