Re: Improve the performance of Unicode Normalization Forms.
Alexander Borisov <lex.borisov@gmail.com>
From: Alexander Borisov <lex.borisov@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-08-01T20:51:04Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Use C11 char16_t and char32_t for Unicode code points.
- 3853a6956c3e 19 (unreleased) cited
01.08.2025 23:37, Tom Lane пишет: > Alexander Borisov <lex.borisov@gmail.com> writes: >> I'm new here, so please advise me: if a patch wasn't accepted at the >> commitfest, does that mean it's not needed (no one was interested in >> it), or was there not enough time? > > It's kind of hard to tell really --- there are many patches in our > queue and not nearly enough reviewers. So maybe someone will get to > it in the fullness of time, or maybe it's true that no one cares > about the particular topic. (But bug fixes and performance > improvements are almost always interesting to someone.) > > I recommend optimism: as long as *you* still believe that the patch > is worthwhile, keep pushing it forward to the next commitfest. > We used to do that automatically, but we have started asking authors > to do that themselves, as a way of weeding out patches for which > the author has lost interest. Thanks, Tom! I always choose optimism. I've been in open source for a while, and this is the first time I've seen this approach. I have a plan to further improve Postgres performance in terms of Unicode (and not only) (which is kind of the foundation for working with text). I don't want to overwhelm the community with patches. I take a systematic approach. Once again, thank you, Tom. The community's approach has become clearer. -- Regards, Alexander Borisov