Hi,
On 2020-01-28 11:10:47 -0500, Robert Haas wrote:
> I generally like this idea, but I'd like to propose that we instead
> replace the NodeTag with a 4-byte magic number. I was studying how
> feasible it would be to make memory contexts available in frontend
> code, and it doesn't look all that bad, but one of the downsides is
> that nodes/memnodes.h includes nodes/nodes.h, and I think it would not
> be a good idea to make frontend code depend on nodes/nodes.h, which
> seems like it's really a backend-only piece of infrastructure. Using a
> magic number would allow us to avoid that, and it doesn't really cost
> anything, because the memory context nodes really don't participate in
> any of that infrastructure anyway.
Hm. I kinda like the idea of still having one NodeTag identifying memory
contexts, and then some additional field identifying the actual
type. Being able to continue to rely on IsA() etc imo is nice. I think
nodes.h itself only would be a problem for frontend code because we put
a lot of other stuff too. We should just separate the actually generic
stuff out. I think it's going to be like 2 seconds once we have memory
contexts until we're e.g. going to want to also have pg_list.h - which
is harder without knowing the tags.
It seems like a good idea to still have an additional identifier for
each node type, for some cross checking. How about just frobbing the
pointer to the MemoryContextMethod slightly, and storing that in an
additional field? That'd be something fairly unlikely to ever be a false
positive, and it doesn't require dereferencing any additional memory.
Greetings,
Andres Freund