Horton

Re: Improper use about DatumGetInt32

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Ashutosh Bapat <ashutosh.bapat@2ndquadrant.com>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>, "Hou, Zhijie" <houzj.fnst@cn.fujitsu.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2020-11-26T13:27:12Z
Lists: pgsql-hackers 
On 2020-Nov-26, Peter Eisentraut wrote:

> The point of the patch is to have the range check somewhere.  If you just
> cast it, then you won't notice out of range arguments.  Note that other
> contrib modules that take block numbers work the same way.

I'm not saying not to do that; just saying we should not propagate it to
places that don't need it.  get_raw_page gets its page number from
PG_GETARG_INT64(), and the range check should be there.  But then it
calls get_raw_page_internal, and it could pass a BlockNumber -- there's
no need to pass an int64.  So get_raw_page_internal does not need a
range check.

Commits

  1. pageinspect: Change block number arguments to bigint

  2. tablefunc: Reject negative number of tuples passed to normal_rand()

  3. Use PG_GETARG_TRANSACTIONID where appropriate