Re: Improper use about DatumGetInt32
От | Peter Eisentraut |
---|---|
Тема | Re: Improper use about DatumGetInt32 |
Дата | |
Msg-id | dc7424f1-7172-341c-45b8-f544b50d03ae@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Improper use about DatumGetInt32 (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: Improper use about DatumGetInt32
|
Список | 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 по дате отправления: