Re: Is custom MemoryContext prohibited?

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, Feb 5, 2020 at 10:09 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> an enum field right in the context. You'll have to do an extra step to
>> discover the context's type, and if you jump to the wrong conclusion
>> and do, say,
>> p *(AllocSetContext *) ptr_value
>> when it's really some other context type, there won't be anything
>> as obvious as "type = T_GenerationContext" in what is printed to
>> tell you you were wrong.

> Doesn't the proposed magic number address this concern?

No, because (a) it will be a random magic number that nobody will
remember, and gdb won't print in any helpful form; (b) at least
as I understood the proposal, there'd be just one magic number for
all types of memory context.

Another issue with relying on only a magic number is that if you
get confused and do "p *(AllocSetContext *) ptr_value" on something
that doesn't point at any sort of memory context at all, there will
not be *anything* except confusing field values to help you realize
that. One of the great advantages of the Node system, IME, is that
when you try to print out a Node-subtype struct, the first field
in what is printed is either the Node type you were expecting, or
some recognizable other Node code, or obvious garbage. If we don't
have an enum field in MemoryContexts then there's not going to be
any similarly-obvious clue that what you're looking at isn't a memory
context in the first place. I'm okay with the enum not being the
first field, but much less okay with not having one at all.

regards, tom lane