On Mon, Jul 15, 2024 at 8:22 PM David Rowley <dgrowleyml@gmail.com> wrote:
> > That said, if you want to go with the integer
> > IDs and want to spend more time massaging it, I also think that's
> > fine. I simply don't believe it's the only way forward here. YMMV, but
> > my opinion is that none of these approaches have such critical flaws
> > that we need to get stressed about it.
>
> If there are other ways forward that match the goal of having a
> reliable way to determine the parent of a MemoryContext, then I'm
> interested in hearing more. I know you've mentioned about having
> unique names, but I don't know how to do that. Do you have any ideas
> on how we could enforce the uniqueness? I don't really like your idea
> of renaming contexts when we find duplicate names as bug fixes. The
> nature of our code wouldn't make it easy to determine as some reusable
> code might create a context as a child of CurrentMemoryContext and
> multiple callers might call that code within a different
> CurrentMemoryContext.
I thought the reason that we have both 'name' and 'ident' was so that
the names could be compile-time constants and the ident values could
be strings, with the idea that we would choose the strings to be
something unique.
But I think I was wrong about that, because I see that for "index
info" contexts we just use the relation name and to have it actually
be unique we'd have to use something like schema_name.relation_name.
And even that wouldn't really work cleanly because the relation could
be renamed or moved to a different schema. Plus, adding string
construction overhead here sounds unappealing.
Maybe we'll find a clever solution someday, but I think for now you're
right that integer IDs are the way to go.
--
Robert Haas
EDB: http://www.enterprisedb.com