On Sat, Aug 30, 2025 at 12:52:45PM -0400, Tom Lane wrote: > Bruce Momjian <[email protected]> writes: > > Second, the release note item added by this commit: > > commit d1073c3b4cc > > Author: Peter Eisentraut <[email protected]> > > Date: Fri Aug 29 10:18:10 2025 +0200 > > > Unfortunately src/tools/add_commit_links.pl can't process the <ulink> > > and throws an error because the previous line does not end with a > > parenthesis. If I add "()" after the last line in the text block, it > > works fine, but obviously this is not acceptable. > > I suppose that the expectation is that every release note item > will be credited to someone. Why does this item lack a credit?
I don't know. > If we're okay with items not having credits, then > add_commit_links.pl's logic for where to put the <ulink>s needs > improvement. I don't really understand why it's looking for > parens in the first place -- why isn't the rule simply "put them > before the first </para> in the item"? I wrote the code to insert the <ulink> when we are not in a comment, when the line is a </para>, _and_ the previous line ends with a parenthesis. Maybe that was overkill, but I wanted to be as restrictive as possible. Actually, in this case, it caught an obvious missing attribution, so it actually helped, so let's not change it. I will add an attribution to Peter Eisentraut now with the attached patch. I also rewrote the item to better match the surrounding text. > In either case, I don't agree with hacky workarounds like manually > munged ulink entries ... > > > I can commit this once our RC1 git tree freeze is over. Is that Tuesday? > > The release freeze doesn't apply to the release notes ;-) Done. ;-) -- Bruce Momjian <[email protected]> https://momjian.us EDB https://enterprisedb.com Do not let urgent matters crowd out time for investment in the future.
diff --git a/doc/src/sgml/release-18.sgml b/doc/src/sgml/release-18.sgml index 2deb5fdd328..d01686f9d07 100644 --- a/doc/src/sgml/release-18.sgml +++ b/doc/src/sgml/release-18.sgml @@ -273,16 +273,20 @@ Author: Peter Eisentraut <[email protected]> <listitem> <para> - The locale implementation underlying full-text search was improved. It - now observes the locale provider configured for the database for case - conversions. It was previously hardcoded to use libc. In database - clusters that use a locale provider other than libc (that is, ICU or - builtin) and where the locale configured through that locale provider - behaves differently from the LC_CTYPE setting configured for the database, - this could cause changes in behavior of some functions related to - full-text search as well as the pg_trgm extension. When upgrading such - database clusters using pg_upgrade, it is recommended to reindex all - indexes related to full-text search and pg_trgm after the upgrade. + Change <link linkend="textsearch">full text search</link> to use the + default collation provider of the cluster to read configuration files + and dictionaries, rather than always using libc (Peter Eisentraut) + </para> + + <para> + Clusters that default to non-libc collation providers (e.g., ICU, + builtin) that behave differently than libc for characters processed + by LC_CTYPE could observe changes in behavior of some full-text + search functions, as well as the <xref linkend="pgtrgm"/> extension. + When upgrading such clusters using <xref linkend="pgupgrade"/>, it + is recommended to reindex all indexes related to full-text search + and <application>pg_trgm</application> after the upgrade. + (Peter Eisentraut) <ulink url="&commit_baseurl;fb1a18810f0">§</ulink> </para> </listitem>
