On Tue, Dec 10, 2019 at 4:59 PM Andres Freund <and...@anarazel.de> wrote: > Neat!
Thanks. > > 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. 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
