Re: Replace references to malloc() in libpq documentation with generic language
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Gurjeet Singh <gurjeet@singh.im>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2023-10-24T15:07:29Z
Lists: pgsql-hackers
Daniel Gustafsson <daniel@yesql.se> writes: >> On 24 Oct 2023, at 07:13, Gurjeet Singh <gurjeet@singh.im> wrote: >> The user does not benefit from knowing that libpq allocates some/all memory >> using malloc(). Mentioning malloc() here has a few downsides, and almost no >> benefits. > I'm not entirely convinced that replacing "malloc" with "allocated on the heap" > improves the documentation. That was my reaction too. The underlying storage allocator *is* malloc, and C programmers know what that is, and I don't see how obfuscating that improves matters. It's true that on the miserable excuse for a platform that is Windows, you have to use PQfreemem because of Microsoft's inability to supply a standards-compliant implementation of malloc. But I'm not inclined to let that tail wag the dog. > I do agree with this proposed change though: > - all the space that will be freed by <xref linkend="libpq-PQclear"/>. > + all the memory that will be freed by <xref linkend="libpq-PQclear"/>. +1, seems harmless. regards, tom lane
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Reword memory terminology for PQresultMemorySize
- d8fd08efbc66 17.0 landed