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

On Wed, 02 Sep 2026 at 17:59, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> wrote:
> 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 have such a place in mind.

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

If there is no code that actually uses it, I don't see a justification for
adding it, especially given the concern about code churn.

>
> Kind regards,
>
> Matthias van de Meent
> Databricks (https://www.databricks.com)

--
Regards,
Japin Li
ChengDu WenWu Information Technology Co., Ltd.