On Mon, Jul 15, 2024 at 8:22 PM David Rowley <dgrowle...@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
