From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, Yugo NAGATA <nagata(at)sraoss(dot)co(dot)jp>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, daniel(at)yesql(dot)se, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Doc: typo in config.sgml |
Date: | 2024-10-15 23:39:01 |
Message-ID: | Zw79FajO3hnIJRuq@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Oct 15, 2024 at 05:59:05PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
> > On Tue, Oct 15, 2024 at 05:27:49PM -0400, Tom Lane wrote:
> >> That policy would cause substantial problems with contributor names
> >> in the release notes. I agree with Peter that we don't need this.
> >> Catching otherwise-invisible characters seems sufficient.
>
> > Uh, why can't we use HTML entities going forward? Is that harder?
>
> Yes: it requires looking up the entities. The mail you are probably
> consulting to make a release note or commit message is most likely
> just going to contain the person's name as normally spelled.
>
> Plus (as you pointed out earlier today) there aren't HTML entities for
> all characters.
>
> > Can we just exclude the release notes from this check?
>
> What is the point of a check we can only enforce against part of the
> documentation?
If people are uncomfortable with a hard requirement, we can convert the
Latin-1 we have now to HTML entities, and then just give people a
command in README.non-ASCII to check for UTF8 if they wish. Patch
attached.
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
When a patient asks the doctor, "Am I going to die?", he means
"Am I going to die soon?"
Attachment | Content-Type | Size |
---|---|---|
latin1.diff | text/x-diff | 8.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2024-10-16 00:12:31 | Re: Large expressions in indexes can't be stored (non-TOASTable) |
Previous Message | Corey Huinker | 2024-10-15 23:36:10 | Re: Statistics Import and Export |