Horton

Re: Improper use about DatumGetInt32

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: "Hou, Zhijie" <houzj.fnst@cn.fujitsu.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2020-09-21T18:08:22Z
Lists: pgsql-hackers 
On Sun, Sep 20, 2020 at 9:17 PM Hou, Zhijie <houzj.fnst@cn.fujitsu.com> wrote:
> In (/contrib/bloom/blutils.c:277), I found it use DatumGetInt32 to get UInt32 type.
> Is it more appropriate to use DatumGetUInt32 here?

Typically, the DatumGetBlah() function that you pick should match the
SQL data type that the function is returning. So if the function
returns pg_catalog.int4, which corresponds to the C data type int32,
you would use DatumGetInt32. There is no SQL type corresponding to the
C data type uint32, so I'm not sure why we even have DatumGetUInt32.
I'm sort of suspicious that there's some fuzzy thinking going on
there.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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