Re: Is custom MemoryContext prohibited? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Is custom MemoryContext prohibited?
Date
Msg-id 2819.1580915341@sss.pgh.pa.us
Whole thread Raw
In response to Re: Is custom MemoryContext prohibited?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Is custom MemoryContext prohibited?
Re: Is custom MemoryContext prohibited?
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Hmm.  What if we put a "const char *name" in the methods array? Then
> even if you couldn't print out the function pointers, you would at
> least see the name.

Yeah, that idea had occurred to me too.  It'd definitely be better than
relying on the ability to interpret function pointers, and there might
be other uses for it besides manual debugging (eg if we had an outfuncs
function for MemoryContext, it could print that).  So I'd be a bit in
favor of adding that independently of this discussion.  I still think
that it'd be inconvenient for debugging, though, compared to having
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.  So I really want to also have an enum
field of some sort, and it does not seem to me that there's any
compelling reason not to have one.

            regards, tom lane



pgsql-hackers by date:

Previous
From: David Christensen
Date:
Subject: Re: Documentation patch for ALTER SUBSCRIPTION
Next
From: Robert Haas
Date:
Subject: Re: [Patch] Optimize dropping of relation buffers using dlist