| From: | "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com> |
|---|---|
| To: | vignesh C <vignesh21(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | RE: StringInfo fixes, v19 edition. Plus a few oddities |
| Date: | 2026-04-23 10:37:07 |
| Message-ID: | TYRPR01MB14195F4AD7E5F240E143E7CB1942A2@TYRPR01MB14195.jpnprd01.prod.outlook.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thursday, April 23, 2026 12:03 AM vignesh C <vignesh21(at)gmail(dot)com> wrote:
> On Sun, 12 Apr 2026 at 06:42, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >
> > David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> > > append_tuple_value_detail() contains some pretty weird translation
> > > strings. The code currently does:
> >
> > > /* translator: This is the terminator of a conflict message */
> > > appendStringInfoString(buf, _("."));
> >
> > > I'm not a translator, but isn't that going to be pretty hard to know
> > > what to do with, given that the same string could be used for
> > > anything else in the code and need something completely different
> > > done? That same function also contains a _(": ") and _(", ") which
> > > seem equally hard to deal with.
> >
> > Yeah, this seems to me to fly in the face of our style guide's rule
> > about "don't construct messages out of parts". And the reason for the
> > rule is precisely that stuff like this poses insoluble problems for
> > translators.
> >
> > I think it'd be reasonable to make this helper function build a string
> > like
> > (value, value, value)
> > with the punctuation being untranslated on the grounds that this is
> > standard SQL notation. Then that could be plugged into a translatable
> > message that might hopefully represent a full sentence with a %s for
> > the tuple data.
>
> I've updated the code to avoid constructing messages from translated
> fragments. append_tuple_value_detail() now only builds a SQL-style tuple
> string like (v1, v2, v3) without any translation or punctuation.
> All punctuation and sentence construction are moved to the callers, which
> now use a single translatable string with a %s placeholder for the tuple data.
> Attached patch has the changes for the same.
The patch seems to change the message content by adding parentheses around the
tuple detail section[1]. However, IIUC, we only need parentheses around the value,
not around the keyword.
[1]
before: ... row to be deleted: replica identity (a)=(10)
After : ... row to be deleted: (replica identity (a)=(10))
Best Regards,
Hou zj
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bertrand Drouvot | 2026-04-23 11:01:02 | Re: Fix DROP PROPERTY GRAPH "unsupported object class" error |
| Previous Message | Álvaro Herrera | 2026-04-23 10:33:53 | Re: EXCEPT TABLE - Case inconsistency for describe \d and \dRp+ |