| From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Declare variable-length catalog columns as [] rather than [1] |
| Date: | 2026-09-22 08:12:37 |
| Message-ID: | E29DAFBC-60AE-4686-8C6A-6AAD8A275790@yesql.se |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On 22 Sep 2026, at 10:00, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>
> On 22/09/2026 10:47, Peter Eisentraut wrote:
>> Variable-length catalog columns have been declared like
>> text attoptions[1];
>> but that "1" has always been a fiction. Before the use of #ifdef CATALOG_VARLEN, these declarations were visible to the C compiler, and this was also before flexible array members were universally available, so this was just a convenient workaround to make this compile. But these reasons are long gone, and the "1" is now just a confusing relic. Change this to
>> text attoptions[];
>> which more intuitively reflects the actual nature of these fields (while still being syntactically valid but semantically invalid C code).
>> Catalog.pm could already parse both spellings, but no existing code used bare []. To enforce future consistency, it is changed to no longer permit digits between the brackets.
>
> +1, looks good to me.
Agreed, that '1' has confused me more than once so glad to see it cleaned up.
--
Daniel Gustafsson
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2026-09-22 08:15:47 | Re: WAL segment file descriptor leak on read errors can PANIC the server |
| Previous Message | Andrey Borodin | 2026-09-22 08:05:42 | Re: sequencesync worker race with REFRESH SEQUENCES |