Re: Improper use about DatumGetInt32 - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Improper use about DatumGetInt32
Date
Msg-id 20201016135630.GA23858@alvherre.pgsql
Whole thread Raw
In response to Re: Improper use about DatumGetInt32  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Responses Re: Improper use about DatumGetInt32
List pgsql-hackers
On 2020-Sep-23, Ashutosh Bapat wrote:

> > You're ignoring the xid use-case, for which DatumGetUInt32 actually is
> > the right thing.
> 
> There is DatumGetTransactionId() which should be used instead.
> That made me search if there's PG_GETARG_TRANSACTIONID() and yes it's
> there but only defined in xid.c. So pg_xact_commit_timestamp(),
> pg_xact_commit_timestamp_origin() and pg_get_multixact_members() use
> PG_GETARG_UNIT32. IMO those should be changed to use
> PG_GETARG_TRANSACTIONID. That would require moving
> PG_GETARG_TRANSACTIONID somewhere outside xid.c; may be fmgr.h where
> other PG_GETARG_* are.

Hmm, yeah, I think this would be a good idea.

> get_raw_page() also does similar thing but the effect is not as dangerous
> SELECT octet_length(get_raw_page('test1', 'main', -1)) AS main_1;
>   ERROR:  block number 4294967295 is out of range for relation "test1"
> Similarly for bt_page_stats() and bt_page_items()

Hmm, but page numbers above signed INT_MAX are valid.  So this would
prevent reading all legitimate pages past that.




pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: CREATE TABLE .. PARTITION OF fails to preserve tgenabled for inherited row triggers
Next
From: Tom Lane
Date:
Subject: Re: upcoming API changes for LLVM 12