public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tom Lane <[email protected]>
To: Kirill Reshke <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: Define DatumGetInt8 function.
Date: Mon, 29 Dec 2025 10:52:58 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <CALdSSPhFyb9qLSHee73XtZm1CBWJNo9+JzFNf-zUEWCRW5yEiQ@mail.gmail.com>
References: <CALdSSPhFyb9qLSHee73XtZm1CBWJNo9+JzFNf-zUEWCRW5yEiQ@mail.gmail.com>

Kirill Reshke <[email protected]> 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

view thread (9+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Define DatumGetInt8 function.
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox