Re: More const-marking cleanup

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: More const-marking cleanup
Date: 2025-12-24 02:47:55
Message-ID: 841907.1766544475@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message jian he 2025-12-24 02:49:57 Re: let ALTER COLUMN SET DATA TYPE cope with POLICY dependency
Previous Message Chao Li 2025-12-24 02:17:56 Fix incorrect buffer lock description in pg_visibility comment