Re: Cleaning up array_ref() and array_set() - Mailing list pgsql-hackers

From Álvaro Herrera
Subject Re: Cleaning up array_ref() and array_set()
Date
Msg-id 202602241635.54v5ghxc6nsq@alvherre.pgsql
Whole thread Raw
In response to Cleaning up array_ref() and array_set()  (David Geier <geidav.pg@gmail.com>)
Responses Re: Cleaning up array_ref() and array_set()
List pgsql-hackers
On 2026-Feb-24, David Geier wrote:

> This has changed over the years. On master there are only 5 calls to
> array_ref() and 5 calls to array_set() left. Are there any objections
> against cleaning up the code by removing array_ref() and array_set()?

I think it would be kinda silly to oppose the removal of use of an
essentially deprecated API for no reason; however, those functions are
used by the GUC machinery directly as exported functions (because the
functions operate on arrays as ArrayType), so if you wanted to change
that, you'd incur in an API break.  So that case is different: would you
want to impose a change on third-party authors that are using these
functions?

For me the answer would be, if we gain something, and the change is easy
for them to make, then sure, let's change it.  If we don't gain
anything, then ... why break things for them?

First example I found on codesearch.debian.net is:
https://sources.debian.org/src/credcheck/4.6-1/credcheck.c?hl=2811#L2811

Maybe it's not a big deal, but that's an assessment that I think should
be made.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"No es bueno caminar con un hombre muerto"



pgsql-hackers by date:

Previous
From: Yura Sokolov
Date:
Subject: Fix bug in multixact Oldest*MXactId initialization and access
Next
From: Nathan Bossart
Date:
Subject: Re: Speed up COPY FROM text/CSV parsing using SIMD