| 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
| 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 |