Horton

Re: Improper use about DatumGetInt32

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, "Hou, Zhijie" <houzj.fnst@cn.fujitsu.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2020-09-22T20:11:01Z
Lists: pgsql-hackers 
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Sep 21, 2020 at 3:53 PM Andres Freund <andres@anarazel.de> wrote:
>> I think we mostly use it for the few places where we currently expose
>> data as a signed integer on the SQL level, but internally actually treat
>> it as a unsigned data.

> So why is the right solution to that not DatumGetInt32() + a cast to uint32?

You're ignoring the xid use-case, for which DatumGetUInt32 actually is
the right thing.  I tend to agree though that if the SQL argument is
of a signed type, the least API-abusing answer is a signed DatumGetXXX
macro followed by whatever cast you need.

			regards, tom lane

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