Alvaro Herrera <alvhe...@alvh.no-ip.org> writes: > My only gripe is the pattern where the identifier needs to be > re-installed when resetting the context. I don't think we need to hold > push for that reason alone, but I bet we'll be revisiting that.
Yeah, that's slightly annoying; if I'd found more than one case of that, I'd want a better answer. But it seems like contexts that are long-lived enough to warrant labeling typically don't get reset during their lifespans, so it shouldn't be a huge problem. I considered having MemoryContextReset either Assert that context->ident is NULL, or just forcibly reset it to NULL, thus preventing a dangling pointer if someone gets this wrong. But that would lock out a perfectly valid coding pattern where the identifier is in the parent context, so I'm not convinced it's a good idea. > I suppose this infrastructure can be used to implement the idea in > https://www.postgresql.org/message-id/camsr+yhii-bcc7ddpbb8fpcgzt0wmrt5gyz0w_kd_ft8rww...@mail.gmail.com > in some more acceptable manner. I'm not proposing it for now, just > parking the idea for a future patch. Ah, I thought I remembered the callback idea from some previous discussion, but I'd not located this one. I think I've got a nicer API for the per-context-type stats functions than what Craig proposes there, but we could imagine doing this API or something close to it for MemoryContextStatsInternal. Or, as I mentioned before, an external caller could just implement the scan over the context tree for itself, and format the data however it wants. regards, tom lane
