| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | "Hou, Zhijie" <houzj(dot)fnst(at)cn(dot)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Improper use about DatumGetInt32 |
| Date: | 2020-09-22 20:02:46 |
| Message-ID: | CA+TgmoY-NprozSN0R3AO+=AoqymLi2fquAscQwD3K-QGjr-Rug@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Sep 21, 2020 at 3:53 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2020-09-21 14:08:22 -0400, Robert Haas wrote:
> > 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.
>
> 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?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-09-22 20:07:10 | Re: Lift line-length limit for pg_service.conf |
| Previous Message | Robert Haas | 2020-09-22 19:41:11 | Re: new heapcheck contrib module |