Re: Expand palloc/pg_malloc API

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Expand palloc/pg_malloc API
Дата
Msg-id 2601938.1658871127@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Expand palloc/pg_malloc API  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Ответы Re: Expand palloc/pg_malloc API  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: Expand palloc/pg_malloc API  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Список pgsql-hackers
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> On 17.05.22 20:43, Tom Lane wrote:
>> So I think Peter's got a good idea here (I might quibble with the details
>> of some of these macros).  But it's not really going to move the
>> safety goalposts very far unless we make a concerted effort to make
>> these be the style everywhere.  Are we willing to do that?  What
>> will it do to back-patching difficulty?  Dare I suggest back-patching
>> these changes?

> I think it could go like the castNode() introduction: first we adopt it 
> sporadically for new code, then we change over some larger pieces of 
> code, then we backpatch the API, then someone sends in a big patch to 
> change the rest.

OK, that seems like a reasonable plan.

I've now studied this a little more closely, and I think the
functionality is fine, but I have naming quibbles.

1. Do we really want distinct names for the frontend and backend
versions of the macros?  Particularly since you're layering the
frontend ones over pg_malloc, which has exit-on-OOM behavior?
I think we've found that notational discrepancies between frontend
and backend code are generally more a hindrance than a help,
so I'm inclined to drop the pg_malloc_xxx macros and just use
"palloc"-based names across the board.

2. I don't like the "palloc_ptrtype" name at all.  I see that you
borrowed that name from talloc, but I doubt that's a precedent that
very many people are familiar with.  To me it sounds like it might
allocate something that's the size of a pointer, not the size of the
pointed-to object.  I have to confess though that I don't have an
obviously better name to suggest.  "palloc_pointed_to" would be
clear perhaps, but it's kind of long.

3. Likewise, "palloc_obj" is perhaps less clear than it could be.
I find palloc_array just fine though.  Maybe palloc_object or
palloc_struct?  (If "_obj" can be traced to talloc, I'm not
seeing where.)


One thought that comes to mind is that palloc_ptrtype is almost
surely going to be used in the style

    myvariable = palloc_ptrtype(myvariable);

and if it's not that it's very likely wrong.  So maybe we should cut
out the middleman and write something like

#define palloc_instantiate(ptr) ((ptr) = (typeof(ptr)) palloc(sizeof(*(ptr))))
...
    palloc_instantiate(myvariable);

I'm not wedded to "instantiate" here, there's probably better names.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Zhihong Yu
Дата:
Сообщение: Question about ExplainOneQuery_hook
Следующее
От: David Rowley
Дата:
Сообщение: Re: Skip partition tuple routing with constant partition key