On 2026-Oct-23, Hannu Krosing wrote: > This is something I have been thinking of for some time and here is a > proof of concept implementation to verify the advantages I have hoped > it will have.
I think you have to stop flooding this list with code that nobody wrote and nobody will read. The pgbench thread is a ridiculous code dump(*). This one looks just like a repeat of that. You should know how this works: a human person needs to take that code and vet it carefully before it becomes part of the distribution. Have a look at the commitfest page; it's flooded with items that need review work, there's a ton of bugfixes that need to be reviewed and backpatched and committed. Each of those things, every line of code, needs careful work, and we just don't have enough people reviewing and finding the huge flaws and the tiny flaws. How do I know there isn't some buffer overflow here that's going to become a CVE next year? A decade ago, companies throwing enormous code dumps over the wall benefitted nobody, because the limiting factor was our ability to review and integrate it. Nowadays, it's even more worthless because anybody can send LLM written code, and tons of it. I want progress here, I really do, but this is not the way. (*) The latest pgbench post was stuck in the moderator queue because of the message size. I was looking at it earlier today, thinking ... 3 MB of code ... should I just reject it? In the end, it's not the moderator's job to take that kind of shot, so it's now published. But you should know better than to post multiple 400kB patches of new features of unknown quality that have never before even been mentioned in this list, much less discussed about or agreed, in a "Refactor pgbench code" subject thread. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "Los trabajadores menos efectivos son sistematicamente llevados al lugar donde pueden hacer el menor daño posible: gerencia." (El principio Dilbert)
