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>, Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: 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-08T15:54:47Z
Lists: pgsql-hackers

Attachments

On 2021-01-08 10:21, Peter Eisentraut wrote:
> I think on 64-bit systems it's actually safe, but on 32-bit systems
> (with USE_FLOAT8_BYVAL), if you use the new binaries with the old
> SQL-level definitions, you'd get the int4 that is passed in interpreted
> as a pointer, which would lead to very bad things.  So I think we need
> to create new functions with a different C symbol.  I'll work on that.

Updated patch that does 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