On Wed, 02 Sep 2026 at 13:36, Matthias van de Meent <[email protected]> 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? > > Kind regards, > > Matthias van de Meent > Databricks (https://www.databricks.com) > > > [^0]: This case for builds with MEMORY_CONTEXT_CHECKING, but builds > with USE_ASSERT_CHECKING or WRITE_READ_PARSE_PLAN_TREES -like options > may also want this. > > [1]: > https://www.postgresql.org/message-id/flat/CAEze2WiPyruOtUOSyRUV8mQssjmYwno0M6hkxC_iUpH-=w8...@mail.gmail.com -- Regards, Japin Li ChengDu WenWu Information Technology Co., Ltd.
