Обсуждение: Define DatumGetInt8 function.

Hi hackers!

I am currently involved in the Cloudberry kernel rebase process[0]. We
are rebasing [0] which is based on pg-14 on pg-16 kernel. During this
process I noticed rebase conflicts introduced  by c8b2ef0. This commit
defines a number of include functions for datum conversion.

During this rebase resolution, I noticed that there is an Int8GetDatum
function, but there is no DatumGetInt8, which I want to use. All other
inline functions seem to be provided in pairs by postgres.h. So it
looks convenient to define DatumGetInt8 in postgres.h?

FPA doing just that.


[0] https://github.com/apache/cloudberry

-- 
Best regards,
Kirill Reshke

> On Dec 29, 2025, at 19:02, Kirill Reshke <reshkekirill@gmail.com> wrote:
> 
> Hi hackers!
> 
> I am currently involved in the Cloudberry kernel rebase process[0]. We
> are rebasing [0] which is based on pg-14 on pg-16 kernel. During this
> process I noticed rebase conflicts introduced  by c8b2ef0. This commit
> defines a number of include functions for datum conversion.
> 
> During this rebase resolution, I noticed that there is an Int8GetDatum
> function, but there is no DatumGetInt8, which I want to use. All other
> inline functions seem to be provided in pairs by postgres.h. So it
> looks convenient to define DatumGetInt8 in postgres.h?
> 
> FPA doing just that.
> 
> 
> [0] https://github.com/apache/cloudberry
> 
> -- 
> Best regards,
> Kirill Reshke
> <v1-0001-Define-DatumGetInt8-function.patch>

LGTM.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

Kirill Reshke <reshkekirill@gmail.com> writes:
> During this rebase resolution, I noticed that there is an Int8GetDatum
> function, but there is no DatumGetInt8, which I want to use. All other
> inline functions seem to be provided in pairs by postgres.h. So it
> looks convenient to define DatumGetInt8 in postgres.h?

I would actually turn this around and ask why we have Int8GetDatum?
We have no SQL types for which that is well-adapted.  I see no
uses of Int8GetDatum in our tree, and only three uses of
UInt8GetDatum, and all three of those look like type puns to me.
(heap_page_items is returning a smallint, and btcharskipsupport
should be using CharGetDatum.)

So from where I sit these look like an attractive nuisance that
we should remove rather than encourage use of.  If you have
some extension data type for which these make sense, that's
fine, but it doesn't mean they should be in core Postgres.

            regards, tom lane

On Mon, 29 Dec 2025 at 20:52, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> So from where I sit these look like an attractive nuisance that
> we should remove rather than encourage use of.  If you have
> some extension data type for which these make sense, that's
> fine, but it doesn't mean they should be in core Postgres.
>
>                         regards, tom lane

Well, OK. Removal is also fine for me, because it is at least consistent.

-- 
Best regards,
Kirill Reshke