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 →
  1. Use C11 char16_t and char32_t for Unicode code points.

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