Hi, On 2019-12-11 10:05:00 -0500, Robert Haas wrote: > On Tue, Dec 10, 2019 at 4:59 PM Andres Freund <and...@anarazel.de> wrote: > > > A significant problem in either case is that a simplehash wants to > > > live in a memory context; no such thing exists either for data in > > > shared memory nor in frontend code. However, it seems to be quite easy > > > to provide a way for simplehash to be defined so that it doesn't care > > > about memory contexts. See 0001. > > > > I wonder if we shouldn't instead just go for an "implicit" memory > > context instead. It's a bit ugly to have a growing set of different > > signatures. > > I don't really know what you mean by this. I don't actually think the > different signatures are a big deal. It affects a pretty limited > number of functions, and that seems less ugly than trying to create > some sort of dummy not-really-a-context object that can live in > frontend code, and a lot easier than actually making contexts work in > frontend code. The latter might be the better long-term solution, but > I don't think we should insist on doing it first.
I was basically just thinking that we could pass the context to use via CurrentMemoryContext, instead of explicitly passing it in. > Another way forward would be to replace the MemoryContext references > with a void * that happens, in the case of the backend, to be a > MemoryContext, and could be NULL when none is required. However, that > would give up some type-checking for no current benefit. If simplehash > becomes more widely used and at some point it's clear that this would > be a net win, we can change it then. Yea, that seems worse. I'd rather work on the MemoryContext infrastructure being available for frontend code. Greetings, Andres Freund
