Horton

Re: Improper use about DatumGetInt32

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>, 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: 2020-12-25T07:45:45Z
Lists: pgsql-hackers 
On Fri, Dec 04, 2020 at 03:58:22PM -0300, Alvaro Herrera wrote:
> I don't know if it's possible to determine (at function execution time)
> that we're running with the old extension version; if so it might
> suffice to throw a warning but still have the SQL function run the same
> C function.

Hmm.  You could look after extversion?  Usually we just handle that
with compatibility routines.

> If we really think that we ought to differentiate, then we could do what
> pg_stat_statement does, and have a separate C function that's called
> with the obsolete signature (pg_stat_statements_1_8 et al).

With the 1.8 flavor, it is possible to pass down a negative number
and it may not fail depending on the number of blocks of the relation,
so I think that you had better have a compatibility layer if a user
has the new binaries but is still on 1.8.  And that's surely a safe
move.
--
Michael

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