Horton

Re: Expand palloc/pg_malloc API

Peter Eisentraut <peter.eisentraut@enterprisedb.com>

View thread View on postgr.es
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-05-24T14:03:27Z
Lists: pgsql-hackers 
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.

Commits

  1. Add repalloc0 and repalloc0_array

  2. Expand palloc/pg_malloc API for more type safety

  3. Assorted examples of expanded type-safer palloc/pg_malloc API