Re: Expand palloc/pg_malloc API
От | Tom Lane |
---|---|
Тема | Re: Expand palloc/pg_malloc API |
Дата | |
Msg-id | 1606160.1652813031@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Expand palloc/pg_malloc API (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Ответы |
Re: Expand palloc/pg_malloc API
|
Список | pgsql-hackers |
Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> writes: > On Tue, May 17, 2022 at 5:11 PM Peter Eisentraut > <peter.eisentraut@enterprisedb.com> wrote: >> This adds additional variants of palloc, pg_malloc, etc. that >> encapsulate common usage patterns and provide more type safety. > I see lots of instances where there's no explicit type-casting to the > target variable type - > retval = palloc(sizeof(GISTENTRY)); > Interval *p = palloc(sizeof(Interval)); > macaddr *v = palloc0(sizeof(macaddr)); and so on. Yeah. IMO the first of those is very poor style, because there's basically nothing enforcing that you wrote the right thing in sizeof(). The others are a bit safer, in that at least a human can note that the two types mentioned on the same line match --- but I doubt any compiler would detect it if they don't. Our current preferred style Interval *p = (Interval *) palloc(sizeof(Interval)); is really barely an improvement, because only two of the three types mentioned are going to be checked against each other. 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? regards, tom lane
В списке pgsql-hackers по дате отправления: