Re: Proposed mid-cycle update of typedefs.list
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2025-12-14T21:38:59Z
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 →
-
Update typedefs.list to match what the buildfarm currently reports.
- 58dad7f349b3 19 (unreleased) landed
-
Make "pgoff_t" be a typedef not a #define.
- 66b2282b0c22 19 (unreleased) landed
Andres Freund <andres@anarazel.de> writes: > On 2025-12-14 14:57:48 -0500, Tom Lane wrote: >> The best theory I can come up with is that 1b105f947 et al >> used these names in palloc0_array and similar calls, and that >> somehow looks like a capturable typedef reference ... but how? > That's indeed curious. I wonder if it's because the return type is cast > differently: Guess it must be. I had thought that our tooling captures types that are used to declare variables or fields of struct variables, but evidently that's not the whole story. One thing we do know for sure is that "sizeof(footype)" does not create a capturable reference to footype. But maybe references within casts do? >> One change I did not apply is that the buildfarm's list omits pgoff_t, >> although we certainly still use that. This is evidently because >> pgoff_t is defined as a macro not a typedef name. I guess we've been >> manually preserving that name in the list, but it seems like we should >> change "#define pgoff_t off_t" to "typedef off_t pgoff_t;" to avoid >> that manual hack. I've not done that here, though. > Sounds like a good idea to me. I'll go deal with these things shortly. regards, tom lane