Re: Is custom MemoryContext prohibited?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Is custom MemoryContext prohibited?
Дата
Msg-id 2819.1580915341@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Is custom MemoryContext prohibited?  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Is custom MemoryContext prohibited?  (Robert Haas <robertmhaas@gmail.com>)
Re: Is custom MemoryContext prohibited?  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: David Christensen
Дата:
Сообщение: Re: Documentation patch for ALTER SUBSCRIPTION
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [Patch] Optimize dropping of relation buffers using dlist