Re: Improper use about DatumGetInt32

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Improper use about DatumGetInt32
Дата
Msg-id 20201016135630.GA23858@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: Improper use about DatumGetInt32  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Ответы Re: Improper use about DatumGetInt32  (Ashutosh Bapat <ashutosh.bapat@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: CREATE TABLE .. PARTITION OF fails to preserve tgenabled for inherited row triggers
Следующее
От: Tom Lane
Дата:
Сообщение: Re: upcoming API changes for LLVM 12