Re: lwlocknames.h beautification attempt
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Álvaro Herrera <alvherre@alvh.no-ip.org>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Gurjeet Singh <gurjeet@singh.im>, Postgres Hackers <pgsql-hackers@postgresql.org>
Date: 2025-03-17T15:38:52Z
Lists: pgsql-hackers
On 2025-Mar-17, Robert Haas wrote: > On Mon, Mar 17, 2025 at 2:43 AM Álvaro Herrera <alvherre@alvh.no-ip.org> wrote: > > Tom didn't say he didn't like this change. He said he didn't like a > > different change, which is not the one I committed. > > Sorry, I should have read the emails more carefully. I missed the fact > that there were two different proposals. It was the idea of > right-aligning things that I was unhappy about. Ah, okay. > So, no objection to what you actually committed... except that I don't > think that using % specifiers in SOME places in a format string is > better than using them in ALL the places. It's not broken because > $lockidx can't contain a % sign, but in general I think when we switch > from print to printf it's better for us to have the format string be a > constant so that it's clear that we can't accidentally get an extra % > escape in there depending on the values of variables being > interpolated. I suppose this is a reasonable complaint; however, I don't see an actual problem here. Even if I hack the regexp in generate-lwlocknames.pl to accept a %-sign in the lock name (and introduce a matching % in wait_event_names.txt), then that % is emitted verbatim rather than attempted to further expand. Is this because this is Perl rather than C? I'm not sure. Note that a % in the lock number (which also needs a regexp hack) can't cause a problem either, because of the check that the lock numbers are an ordered sequence. I think it's quite difficult to cause actual problems here. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Make lwlocknames.h generated file less ugly
- da0f0582e81e 18.0 landed