Re: Declare variable-length catalog columns as [] rather than [1]

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

In response to

Browse pgsql-hackers by date

  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