Re: glist: _Generic wrapper for selective dlist/dclist usage

On Wed, 2 Sept 2026 at 17:32, Japin Li <japinli(at)hotmail(dot)com> wrote:
>
> On Wed, 02 Sep 2026 at 13:36, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> wrote:
> > Hi,
> >
> > I'd like to track the size of a dlist for data structure validation
> > purposes[^0]. Normally, one would use a dclist, as this tracks a
> > count of list elements contained therein, but because this code would
> > not be called in most normal production builds using a dclist would
> > waste precious memory.
> > Manually tracking the length is possible, but tedious, and a local
> > wrapper around the used dclist/dlist APIs (with different
> > implementations conditioned with #ifdefs to use the right types) would
> > also be a significant amount of effort, that'd be duplicated every
> > time .
> >
> > Attached is a patch that adds glist_* macros, which wrap several
> > dlist/dclist_* APIs, so that developers can use dlist/dclist
> > selectively in different environments, without significant visual
> > overhead in the code. I'm planning to use this in the Proxy memory
> > contexts over at [1].
> >
> > I've considered also adding slist_* to the macros, but I've never
> > needed selective slist vs dlist/dclist before, so I ignored that list
> > type for now.
> >
>
> +1 for this idea.
>
> Should we adopt the new glist interface in the existing code to better
> showcase its intended use?

Did you have a place in mind where we have dlist and dclist in use to
track the same information in different build configurations? I don't
like churning code for the sake of new APIs, especially when those new
APIs are not strictly better than the current ones.

Note that I add glist to solve ergonomics issues when you want to
handle both types of lists. It's not meant to be used as default API
to fields that are always of a dlist type, or always of a dclist type,
even if it could be used like that.

Kind regards,

Matthias van de Meent
Databricks (https://www.databricks.com)