Re: Expand palloc/pg_malloc API - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Expand palloc/pg_malloc API
Date
Msg-id CA+Tgmoav7PX2sNX6twMRc5cvi=wyBTqRRxZSocgMMx0DFAvsWw@mail.gmail.com
Whole thread Raw
In response to Re: Expand palloc/pg_malloc API  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: Expand palloc/pg_malloc API
List pgsql-hackers
On Fri, Aug 12, 2022 at 3:31 AM Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
> (Personally, I have always been a bit suspicious about using the name
> palloc() without memory context semantics in frontend code, but I guess
> this is wide-spread now.)

I think it would be a good thing to add memory context support to the
frontend. We could just put everything in a single context for
starters, and then frontend utilities that wanted to create other
contexts could do so.

There are difficulties, though. For instance, memory contexts are
nodes, and have a NodeTag. And I'm pretty sure we don't want frontend
code to know about all the backend node types. My suspicion is that
memory context types really shouldn't be node types, but right now,
they are. Whether that's the correct view or not, this kind of problem
means it's not a simple lift-and-shift to move the memory context code
into src/common. Someone would need to spend some time thinking about
how to engineer it.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: replacing role-level NOINHERIT with a grant-level option
Next
From: Tomas Vondra
Date:
Subject: Re: Reducing the chunk header sizes on all memory context types