Re: [COMMITTERS] pgsql: pageinspect: Try to fix some bugs in previous commit.

From: Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: pageinspect: Try to fix some bugs in previous commit.
Date: 2017-02-06 05:02:03
Message-ID: CAE9k0PmymswZwgP=vzxY1pjzsPtnrFqy6WhxFRdEE2kH0tMeBg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

>>>> I think UInt32GetDatum(metad->hashm_procid) looks fine, the reason
>>>> being 'hashm_procid' is defined as 32-bit unsigned integer but then we
>>>> may have to define procid as int8 in SQL function.
>>>
>>> No, you're wrong. The GetDatum you choose macro has to match the SQL
>>> type, not the type of the variable that you're passing to it. For
>>> example, if you've got an "int" in the code and the SQL type is
>>> "int8", you have to use Int64GetDatum, not Int32GetDatum. Otherwise,
>>> stuff breaks, because on some systems 64-bit integers are passed by
>>> reference, not by value, so the representation that Int32GetDatum
>>> produces isn't valid when interpreted by DatumGetInt64 later on. The
>>> latter is expecting a pointer, but the former didn't produce one.
>>>
>>
>> Thank you very much for detailed information and explanation. It is
>> really very helpful and understandable. But, As per your explanation,
>> GetDatum we choose need to match the SQL type, not the type of the
>> variable used in code and I do not see any unsigned integer SQL type
>> in PostgreSQL then I am just wondering on why do we have
>> UInt32GetDatum or UInt64GetDatum macros.
>
> That's a pretty good question. UInt64GetDatum is used in exactly one
> place (exec_stmt_getdiag) and there's really no reason why
> Int64GetDatum wouldn't be more appropriate. UInt32GetDatum is used in
> a few more places, and some of those are used for hash values which
> are not exposed at the SQL level so they might be legitimate, but
> others like the ones in pageinspect look like fuzzy thinking that has
> only survived because it happens not to break anything. I suppose if
> we wanted to be really rigorous about this sort of thing, we should
> change UInt32GetDatum to do something tangibly different from
> Int32GetDatum, like negate all the bits. Then if somebody picked the
> wrong macro it would actually fail. I'm not sure that's really the
> best place to spend our effort, though. The moral of this episode is
> that it's important to at least get the right width. Currently,
> getting the wrong signedness doesn't actually break anything.

Okay, understood. Thank you very much !

--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Heikki Linnakangas 2017-02-06 09:40:50 pgsql: Fix typos in comments.
Previous Message Robert Haas 2017-02-05 23:50:38 Re: [COMMITTERS] pgsql: pageinspect: Try to fix some bugs in previous commit.

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-02-06 05:04:40 Re: 0/NULL/NIL assignments in build_*_rel()
Previous Message Michael Paquier 2017-02-06 04:52:50 Re: Provide list of subscriptions and publications in psql's completion