Hello Evan,
On 2026-Feb-02, Chao Li wrote:
> I don't think we necessarily need to add a simple_int_list. Since OIDs
> are not globally unique across all object types, we can reasonably
> treat ControlData items as "objects" and assign them OIDs within this
> context.
>
> If we take that approach, the enum could be named ControlDataOid:
> ```
> /* Define the string enums */
> #define CONTROLDATA_LINE(symbol, description, fmt, ...) \
> symbol,
> enum {
> #include "entries.h”
> } ControlDataOid;
> #undef CONTROLDATA_LINE
> ```
>
> This makes reusing simple_oid_list feel appropriate.
True, but that's a bit cheating with the naming. Really, type Oid is
related to identifying database objects, that is, what is used in each
catalog row. Someday we may want to decide to enlarge that to 64 bits,
and if that happens and yet the C compiler continues to use 32-bit
integers to implement C-level enums, which is what this patch uses, what
then?
If I go with just simple_int_list, then that's always (by definition)
going to be a C integer, which is (presumably) always going to be what
the C compiler uses to implement a C enum.
(I think in reality we're unlikely to change Oid to be 64-bit, because
there's no reason to do so since it's quite unusual to have such very
many database objects. I think it's more likely that we'd change the
type that underlies TOAST pointers, which is where the real problem with
Oid resides. Even so, it seems ... dangerous? ... to me to do what
you propose.)
> If you aren't fond of that idea, I’d suggest naming the enum
> ControlDataSymbol rather than ControlDataStrings, as the former better
> reflects what the members actually are.
Yeah, this is probably a good idea anyway, given that these objects are
not strings anymore.
Thanks for the review!
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
