On Tue, Jan 03, 2023 at 04:28:29PM +0900, Michael Paquier wrote: > On Fri, Dec 30, 2022 at 05:12:57PM -0600, Justin Pryzby wrote: > > # Use larger ccache cache, as this task compiles with multiple compilers > / > # flag combinations > - CCACHE_MAXSIZE: "1GB" > + CCACHE_MAXSIZE: "1G" > > In 0006, I am not sure how much this matters. Perhaps somebody more > fluent with Cirrus, though, has a different opinion..
It's got almost nothing to do with cirrus. It's an environment variable, and we're using a suffix other than what's supported/documented by ccache, which only happens to work. > 0014 and 0013 do not reduce the translation workload, as the messages > include some stuff specific to the GUC names accessed to, or some > specific details about the code paths triggered. It seems to matter because otherwise the translators sometimes re-type the view name, which (not surprisingly) can get messed up, which is how I mentioned having noticed this. On Tue, Jan 03, 2023 at 05:41:58PM +0900, Michael Paquier wrote: > On Tue, Jan 03, 2023 at 01:03:01PM +0530, Amit Kapila wrote: > > One minor comment: > > - spoken in Belgium (BE), with a <acronym>UTF-8</acronym> > > character set > > + spoken in Belgium (BE), with a <acronym>UTF</acronym>-8 > > character set > > > > Shouldn't this be <acronym>UTF8</acronym> as we are using in > > func.sgml? > > Yeah, I was wondering as well why this change is not worse, which is > why I left it out of 33ab0a2. There is an acronym for UTF in > acronym.sgml, which makes sense to me, but that's the only place where > this is used. To add more on top of that, the docs basically need > only UTF8, and we have three references to UTF-16, none of them using > the <acronym> markup. I changed it for consistency, as it's the only thing that says <>UTF-8<> anywhere, and charset.sgml already says <>UTF<>-8 elsewhere. Alternately, I suggest to change charset to say <>UTF8<> in both places. -- Justin