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

From Peter Eisentraut
Subject Re: Improper use about DatumGetInt32
Date
Msg-id dc7424f1-7172-341c-45b8-f544b50d03ae@enterprisedb.com
Whole thread Raw
In response to Re: Improper use about DatumGetInt32  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: Improper use about DatumGetInt32  (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>)
List pgsql-hackers
On 2020-11-26 14:27, Alvaro Herrera wrote:
> 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.

Yeah, I had it like that for a moment, but then you need to duplicate 
the check in get_raw_page() and get_raw_page_fork().  I figured since 
get_raw_page_internal() does all the other argument checking also, it 
seems sensible to put the block range check there too.  But it's not a 
big deal either way.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: configure and DocBook XML
Next
From: Paul Förster
Date:
Subject: Re: configure and DocBook XML