From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: typos |
Date: | 2023-01-10 06:54:40 |
Message-ID: | CAA4eK1+OPcKAQneTu=2byxiRS07-NVmN0QwUFEHHw2N5osKoWw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jan 10, 2023 at 10:27 AM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
>
> On Tue, Jan 03, 2023 at 03:39:22PM -0600, Justin Pryzby wrote:
> > 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.
>
> As attached.
> This also fixes "specualtive" in Amit's recent commit.
>
Thanks for noticing this. I'll take care of this and some other typo
patches together.
--
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2023-01-10 07:24:33 | Re: FYI: 2022-10 thorntail failures from coreutils FICLONE |
Previous Message | Amit Kapila | 2023-01-10 06:31:43 | Re: Perform streaming logical transactions by background workers and parallel apply |