Re: More const-marking cleanup

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>

To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>

Cc: pgsql-hackers@lists.postgresql.org

Date: 2025-12-24T02:47:55Z

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 →

Fix some cases of indirectly casting away const.
- de77775a7b50 18.4 landed
- cc9c22a5160a 15.18 landed
- a56a70141e09 17.10 landed
- 244c047205bb 14.23 landed
- 0969bfd0db86 16.14 landed
- 8f1791c61836 19 (unreleased) landed
Fix another case of indirectly casting away const.
- 9f7565c6c2d4 19 (unreleased) landed
ecpg: refactor to eliminate cast-away-const in find_variable().
- 4eda42e8bdf5 19 (unreleased) landed

Bertrand Drouvot <bertranddrouvot.pg@gmail.com> writes:
> I had another look and it seems to me that the one (src/port/getopt.c) reported
> and fixed in the attached of the previous email is the only remaining one to fix.

This fell off my radar for a bit, but pushed now.  Thanks for
catching it.

This does raise a question in my mind though: we did not find this
case the first time around because machines that have new-enough
compilers to detect such issues will probably not need our version of
getopt().  So, what other not-always-compiled bits of code could use
improvement, and how could we find them without undue effort?  (This
extends to more issues than just casting-away-const of course.)

			regards, tom lane