Re: Expand palloc/pg_malloc API

On 26.07.22 23:32, Tom Lane wrote:
> 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.

This seems like a question that is independent of this patch. Given
that both pg_malloc() and palloc() do exist in fe_memutils, I think it
would be confusing to only extend one part of that and not the other.
The amount of code is ultimately not a lot.

If we wanted to get rid of pg_malloc() altogether, maybe we could talk
about that.

(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.)

> 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.)

In talloc, the talloc() function itself allocates an object of a given
type. To allocate something of a specified size, you'd use
talloc_size(). So those names won't map exactly. I'm fine with
palloc_object() if that is clearer.

> 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);

Right, this is sort of what you'd want, really. But it looks like
strange C code, since you are modifying the variable even though you are
passing it by value.

I think the _ptrtype variant isn't that useful anyway, so if it's
confusing we can leave it out.