Re: Expand palloc/pg_malloc API

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Expand palloc/pg_malloc API
Дата
Msg-id CA+Tgmoav7PX2sNX6twMRc5cvi=wyBTqRRxZSocgMMx0DFAvsWw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Expand palloc/pg_malloc API  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Ответы Re: Expand palloc/pg_malloc API  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: replacing role-level NOINHERIT with a grant-level option
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: Reducing the chunk header sizes on all memory context types