Horton

Re: Improper use about DatumGetInt32

Peter Eisentraut <peter.eisentraut@enterprisedb.com>

View thread View on postgr.es
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>, 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: 2021-01-13T08:27:37Z
Lists: pgsql-hackers

Attachments

On 2021-01-11 09:09, Michael Paquier wrote:
> On Sat, Jan 09, 2021 at 01:41:39PM +0100, Peter Eisentraut wrote:
>> If we had a way to do such testing then we wouldn't need these markers. But
>> AFAICT, we don't.
> 
> Not sure I am following your point here.  Taking your patch, it is
> possible to trigger the version of get_raw_page() <= 1.8 just with
> something like the following:
> create extension pageinspect version "1.8";
> select get_raw_page('pg_class', 0);
> 
> There are no in-core regression tests that check the compatibility of
> extensions with older versions, but it is technically possible to do
> so.

Interesting idea.  Here is a patch that incorporates that.

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