| From: | Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | glist: _Generic wrapper for selective dlist/dclist usage |
| Date: | 2026-09-02 11:36:12 |
| Message-ID: | CAEze2WjUs6P1QCUHij9WOnkS7CX+tvVqRiFiGdXoyevh417h4A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
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.
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-ilist.h-Introduce-glist-convenience-macros.patch | application/octet-stream | 5.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thom Brown | 2026-09-02 11:48:15 | REPACK (CONCURRENTLY) can crash a logical decoding session |
| Previous Message | Jakob Egger | 2026-09-02 11:27:38 | Re: glob support in extension_control_path/dynamic_library_path? |