Re: allowing broader use of simplehash

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: allowing broader use of simplehash
Date: 2019-12-11 15:05:00
Message-ID: CA+TgmoZ7nj8x1epPJJx0bx3-phzGzKBBkoQtW_uBJWvcr4XA7g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 10, 2019 at 4:59 PM Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-12-11 15:06:37 Re: BUG #16059: Tab-completion of filenames in COPY commands removes required quotes
Previous Message Justin Pryzby 2019-12-11 14:36:48 Re: error context for vacuum to include block number