From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Expand palloc/pg_malloc API |
Date: | 2022-08-12 07:39:43 |
Message-ID: | 8a844750-ba6a-4a32-3bc9-2ba73224b4df@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 27.07.22 01:58, David G. Johnston wrote:
> Admittedly I'm still getting my head around reading pointer-using code
> (I get the general concept but haven't had to code them)....
>
> - lockrelid = palloc(sizeof(*lockrelid));
> + lockrelid = palloc_ptrtype(lockrelid);
>
> // This definitely seems like an odd idiom until I remembered about
> short-lived memory contexts and the lost pointers are soon destroyed there.
>
> So lockrelid (no star) is a pointer that has an underlying reference
> that the macro (and the orignal code) resolves via the *
>
> I cannot reason out whether the following would be equivalent to the above:
>
> lockrelid = palloc_obj(*lockrelid);
I think that would also work.
Ultimately, it would be more idiomatic (in Postgres), to write this as
lockrelid = palloc(sizeof(LockRelId));
and thus
lockrelid = palloc_obj(LockRelId);
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2022-08-12 07:42:30 | Re: Cleaning up historical portability baggage |
Previous Message | Peter Eisentraut | 2022-08-12 07:31:40 | Re: Expand palloc/pg_malloc API |