postgresql/src/include/postgres.h

574 lines
11 KiB
C
Raw Normal View History

1996-10-31 02:10:14 -05:00
/*-------------------------------------------------------------------------
*
* postgres.h
* Primary include file for PostgreSQL server .c files
*
* This should be the first file included by PostgreSQL backend modules.
* Client-side code should include postgres_fe.h instead.
*
1996-10-31 02:10:14 -05:00
*
* Portions Copyright (c) 1996-2026, PostgreSQL Global Development Group
* Portions Copyright (c) 1995, Regents of the University of California
1996-10-31 02:10:14 -05:00
*
2010-09-20 16:08:53 -04:00
* src/include/postgres.h
1996-10-31 02:10:14 -05:00
*
*-------------------------------------------------------------------------
*/
/* IWYU pragma: always_keep */
1996-10-31 02:10:14 -05:00
/*
*----------------------------------------------------------------
* TABLE OF CONTENTS
1996-10-31 02:10:14 -05:00
*
* When adding stuff to this file, please try to put stuff
* into the relevant section, or add new sections as appropriate.
1996-10-31 02:10:14 -05:00
*
* section description
* ------- ------------------------------------------------
* 1) Datum type + support functions
* 2) miscellaneous
1996-10-31 02:10:14 -05:00
*
* NOTES
*
* In general, this file should contain declarations that are widely needed
* in the backend environment, but are of no interest outside the backend.
*
* Simple type definitions live in c.h, where they are shared with
* postgres_fe.h. We do that since those type definitions are needed by
* frontend modules that want to deal with binary data transmission to or
* from the backend. Type definitions in this file should be for
* representations that never escape the backend, such as Datum.
*
*----------------------------------------------------------------
1996-10-31 02:10:14 -05:00
*/
#ifndef POSTGRES_H
#define POSTGRES_H
/* IWYU pragma: begin_exports */
1996-10-31 02:10:14 -05:00
#include "c.h"
#include "utils/elog.h"
1999-07-16 13:07:40 -04:00
#include "utils/palloc.h"
1996-10-31 02:10:14 -05:00
/* IWYU pragma: end_exports */
1996-10-31 02:10:14 -05:00
/* ----------------------------------------------------------------
* Section 1: Datum type + support functions
* ----------------------------------------------------------------
*/
/*
* A Datum contains either a value of a pass-by-value type or a pointer to a
Make type Datum be 8 bytes wide everywhere. This patch makes sizeof(Datum) be 8 on all platforms including 32-bit ones. The objective is to allow USE_FLOAT8_BYVAL to be true everywhere, and in consequence to remove a lot of code that is specific to pass-by-reference handling of float8, int8, etc. The code for abbreviated sort keys can be simplified similarly. In this way we can reduce the maintenance effort involved in supporting 32-bit platforms, without going so far as to actually desupport them. Since Datum is strictly an in-memory concept, this has no impact on on-disk storage, though an initdb or pg_upgrade will be needed to fix affected catalog entries. We have required platforms to support [u]int64 for ages, so this breaks no supported platform. We can expect that this change will make 32-bit builds a bit slower and more memory-hungry, although being able to use pass-by-value handling of 8-byte types may buy back some of that. But we stopped optimizing for 32-bit cases a long time ago, and this seems like just another step on that path. This initial patch simply forces the correct type definition and USE_FLOAT8_BYVAL setting, and cleans up a couple of minor compiler complaints that ensued. This is sufficient for testing purposes. In the wake of a bunch of Datum-conversion cleanups by Peter Eisentraut, this now compiles cleanly with gcc on a 32-bit platform. (I'd only tested the previous version with clang, which it turns out is less picky than gcc about width-changing coercions.) There is a good deal of now-dead code that I'll remove in separate follow-up patches. A catversion bump is required because this affects initial catalog contents (on 32-bit machines) in two ways: pg_type.typbyval changes for some built-in types, and Const nodes in stored views/rules will now have 8 bytes not 4 for pass-by-value types. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Discussion: https://postgr.es/m/1749799.1752797397@sss.pgh.pa.us
2025-08-13 16:35:06 -04:00
* value of a pass-by-reference type. Therefore, we must have
* sizeof(Datum) >= sizeof(void *). No current or foreseeable Postgres
* platform has pointers wider than 8 bytes, and standardizing on Datum being
* exactly 8 bytes has advantages in reducing cross-platform differences.
*
* The functions below and the analogous functions for other types should be used to
* convert between a Datum and the appropriate C type.
*/
Make type Datum be 8 bytes wide everywhere. This patch makes sizeof(Datum) be 8 on all platforms including 32-bit ones. The objective is to allow USE_FLOAT8_BYVAL to be true everywhere, and in consequence to remove a lot of code that is specific to pass-by-reference handling of float8, int8, etc. The code for abbreviated sort keys can be simplified similarly. In this way we can reduce the maintenance effort involved in supporting 32-bit platforms, without going so far as to actually desupport them. Since Datum is strictly an in-memory concept, this has no impact on on-disk storage, though an initdb or pg_upgrade will be needed to fix affected catalog entries. We have required platforms to support [u]int64 for ages, so this breaks no supported platform. We can expect that this change will make 32-bit builds a bit slower and more memory-hungry, although being able to use pass-by-value handling of 8-byte types may buy back some of that. But we stopped optimizing for 32-bit cases a long time ago, and this seems like just another step on that path. This initial patch simply forces the correct type definition and USE_FLOAT8_BYVAL setting, and cleans up a couple of minor compiler complaints that ensued. This is sufficient for testing purposes. In the wake of a bunch of Datum-conversion cleanups by Peter Eisentraut, this now compiles cleanly with gcc on a 32-bit platform. (I'd only tested the previous version with clang, which it turns out is less picky than gcc about width-changing coercions.) There is a good deal of now-dead code that I'll remove in separate follow-up patches. A catversion bump is required because this affects initial catalog contents (on 32-bit machines) in two ways: pg_type.typbyval changes for some built-in types, and Const nodes in stored views/rules will now have 8 bytes not 4 for pass-by-value types. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Discussion: https://postgr.es/m/1749799.1752797397@sss.pgh.pa.us
2025-08-13 16:35:06 -04:00
typedef uint64_t Datum;
/*
* This symbol is now vestigial, but we continue to define it so as not to
* unnecessarily break extension code.
*/
#define SIZEOF_DATUM 8
2003-08-03 20:43:34 -04:00
Change function call information to be variable length. Before this change FunctionCallInfoData, the struct arguments etc for V1 function calls are stored in, always had space for FUNC_MAX_ARGS/100 arguments, storing datums and their nullness in two arrays. For nearly every function call 100 arguments is far more than needed, therefore wasting memory. Arg and argnull being two separate arrays also guarantees that to access a single argument, two cachelines have to be touched. Change the layout so there's a single variable-length array with pairs of value / isnull. That drastically reduces memory consumption for most function calls (on x86-64 a two argument function now uses 64bytes, previously 936 bytes), and makes it very likely that argument value and its nullness are on the same cacheline. Arguments are stored in a new NullableDatum struct, which, due to padding, needs more memory per argument than before. But as usually far fewer arguments are stored, and individual arguments are cheaper to access, that's still a clear win. It's likely that there's other places where conversion to NullableDatum arrays would make sense, e.g. TupleTableSlots, but that's for another commit. Because the function call information is now variable-length allocations have to take the number of arguments into account. For heap allocations that can be done with SizeForFunctionCallInfoData(), for on-stack allocations there's a new LOCAL_FCINFO(name, nargs) macro that helps to allocate an appropriately sized and aligned variable. Some places with stack allocation function call information don't know the number of arguments at compile time, and currently variably sized stack allocations aren't allowed in postgres. Therefore allow for FUNC_MAX_ARGS space in these cases. They're not that common, so for now that seems acceptable. Because of the need to allocate FunctionCallInfo of the appropriate size, older extensions may need to update their code. To avoid subtle breakages, the FunctionCallInfoData struct has been renamed to FunctionCallInfoBaseData. Most code only references FunctionCallInfo, so that shouldn't cause much collateral damage. This change is also a prerequisite for more efficient expression JIT compilation (by allocating the function call information on the stack, allowing LLVM to optimize it away); previously the size of the call information caused problems inside LLVM's optimizer. Author: Andres Freund Reviewed-By: Tom Lane Discussion: https://postgr.es/m/20180605172952.x34m5uz6ju6enaem@alap3.anarazel.de
2019-01-26 17:17:52 -05:00
/*
* A NullableDatum is used in places where both a Datum and its nullness needs
* to be stored. This can be more efficient than storing datums and nullness
* in separate arrays, due to better spatial locality, even if more space may
* be wasted due to padding.
*/
typedef struct NullableDatum
{
#define FIELDNO_NULLABLE_DATUM_DATUM 0
Datum value;
#define FIELDNO_NULLABLE_DATUM_ISNULL 1
bool isnull;
/* due to alignment padding this could be used for flags for free */
} NullableDatum;
/*
* DatumGetBool
* Returns boolean value of a datum.
*
* Note: any nonzero value will be considered true.
*/
static inline bool
DatumGetBool(Datum X)
{
return (X != 0);
}
/*
* BoolGetDatum
* Returns datum representation for a boolean.
*
* Note: any nonzero value will be considered true.
*/
static inline Datum
BoolGetDatum(bool X)
{
return (Datum) (X ? 1 : 0);
}
/*
* DatumGetChar
* Returns character value of a datum.
*/
static inline char
DatumGetChar(Datum X)
{
return (char) X;
}
/*
* CharGetDatum
* Returns datum representation for a character.
*/
static inline Datum
CharGetDatum(char X)
{
return (Datum) X;
}
/*
* Int8GetDatum
* Returns datum representation for an 8-bit integer.
*/
static inline Datum
Int8GetDatum(int8 X)
{
return (Datum) X;
}
/*
* DatumGetUInt8
* Returns 8-bit unsigned integer value of a datum.
*/
static inline uint8
DatumGetUInt8(Datum X)
{
return (uint8) X;
}
/*
* UInt8GetDatum
* Returns datum representation for an 8-bit unsigned integer.
*/
static inline Datum
UInt8GetDatum(uint8 X)
{
return (Datum) X;
}
/*
* DatumGetInt16
* Returns 16-bit integer value of a datum.
*/
static inline int16
DatumGetInt16(Datum X)
{
return (int16) X;
}
/*
* Int16GetDatum
* Returns datum representation for a 16-bit integer.
*/
static inline Datum
Int16GetDatum(int16 X)
{
return (Datum) X;
}
/*
* DatumGetUInt16
* Returns 16-bit unsigned integer value of a datum.
*/
static inline uint16
DatumGetUInt16(Datum X)
{
return (uint16) X;
}
/*
* UInt16GetDatum
* Returns datum representation for a 16-bit unsigned integer.
*/
static inline Datum
UInt16GetDatum(uint16 X)
{
return (Datum) X;
}
/*
* DatumGetInt32
* Returns 32-bit integer value of a datum.
*/
static inline int32
DatumGetInt32(Datum X)
{
return (int32) X;
}
/*
* Int32GetDatum
* Returns datum representation for a 32-bit integer.
*/
static inline Datum
Int32GetDatum(int32 X)
{
return (Datum) X;
}
/*
* DatumGetUInt32
* Returns 32-bit unsigned integer value of a datum.
*/
static inline uint32
DatumGetUInt32(Datum X)
{
return (uint32) X;
}
/*
* UInt32GetDatum
* Returns datum representation for a 32-bit unsigned integer.
*/
static inline Datum
UInt32GetDatum(uint32 X)
{
return (Datum) X;
}
/*
* DatumGetObjectId
* Returns object identifier value of a datum.
*/
static inline Oid
DatumGetObjectId(Datum X)
{
return (Oid) X;
}
/*
* ObjectIdGetDatum
* Returns datum representation for an object identifier.
*/
static inline Datum
ObjectIdGetDatum(Oid X)
{
return (Datum) X;
}
/*
* DatumGetObjectId8
* Returns 8-byte object identifier value of a datum.
*/
static inline Oid8
DatumGetObjectId8(Datum X)
{
return (Oid8) X;
}
/*
* ObjectId8GetDatum
* Returns datum representation for an 8-byte object identifier
*/
static inline Datum
ObjectId8GetDatum(Oid8 X)
{
return (Datum) X;
}
/*
* DatumGetTransactionId
* Returns transaction identifier value of a datum.
*/
static inline TransactionId
DatumGetTransactionId(Datum X)
{
return (TransactionId) X;
}
/*
* TransactionIdGetDatum
* Returns datum representation for a transaction identifier.
*/
static inline Datum
TransactionIdGetDatum(TransactionId X)
{
return (Datum) X;
}
Improve concurrency of foreign key locking This patch introduces two additional lock modes for tuples: "SELECT FOR KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each other, in contrast with already existing "SELECT FOR SHARE" and "SELECT FOR UPDATE". UPDATE commands that do not modify the values stored in the columns that are part of the key of the tuple now grab a SELECT FOR NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently with tuple locks of the FOR KEY SHARE variety. Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this means the concurrency improvement applies to them, which is the whole point of this patch. The added tuple lock semantics require some rejiggering of the multixact module, so that the locking level that each transaction is holding can be stored alongside its Xid. Also, multixacts now need to persist across server restarts and crashes, because they can now represent not only tuple locks, but also tuple updates. This means we need more careful tracking of lifetime of pg_multixact SLRU files; since they now persist longer, we require more infrastructure to figure out when they can be removed. pg_upgrade also needs to be careful to copy pg_multixact files over from the old server to the new, or at least part of multixact.c state, depending on the versions of the old and new servers. Tuple time qualification rules (HeapTupleSatisfies routines) need to be careful not to consider tuples with the "is multi" infomask bit set as being only locked; they might need to look up MultiXact values (i.e. possibly do pg_multixact I/O) to find out the Xid that updated a tuple, whereas they previously were assured to only use information readily available from the tuple header. This is considered acceptable, because the extra I/O would involve cases that would previously cause some commands to block waiting for concurrent transactions to finish. Another important change is the fact that locking tuples that have previously been updated causes the future versions to be marked as locked, too; this is essential for correctness of foreign key checks. This causes additional WAL-logging, also (there was previously a single WAL record for a locked tuple; now there are as many as updated copies of the tuple there exist.) With all this in place, contention related to tuples being checked by foreign key rules should be much reduced. As a bonus, the old behavior that a subtransaction grabbing a stronger tuple lock than the parent (sub)transaction held on a given tuple and later aborting caused the weaker lock to be lost, has been fixed. Many new spec files were added for isolation tester framework, to ensure overall behavior is sane. There's probably room for several more tests. There were several reviewers of this patch; in particular, Noah Misch and Andres Freund spent considerable time in it. Original idea for the patch came from Simon Riggs, after a problem report by Joel Jacobson. Most code is from me, with contributions from Marti Raudsepp, Alexander Shulgin, Noah Misch and Andres Freund. This patch was discussed in several pgsql-hackers threads; the most important start at the following message-ids: AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com 1290721684-sup-3951@alvh.no-ip.org 1294953201-sup-2099@alvh.no-ip.org 1320343602-sup-2290@alvh.no-ip.org 1339690386-sup-8927@alvh.no-ip.org 4FE5FF020200002500048A3D@gw.wicourts.gov 4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 10:04:59 -05:00
/*
* MultiXactIdGetDatum
* Returns datum representation for a multixact identifier.
Improve concurrency of foreign key locking This patch introduces two additional lock modes for tuples: "SELECT FOR KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each other, in contrast with already existing "SELECT FOR SHARE" and "SELECT FOR UPDATE". UPDATE commands that do not modify the values stored in the columns that are part of the key of the tuple now grab a SELECT FOR NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently with tuple locks of the FOR KEY SHARE variety. Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this means the concurrency improvement applies to them, which is the whole point of this patch. The added tuple lock semantics require some rejiggering of the multixact module, so that the locking level that each transaction is holding can be stored alongside its Xid. Also, multixacts now need to persist across server restarts and crashes, because they can now represent not only tuple locks, but also tuple updates. This means we need more careful tracking of lifetime of pg_multixact SLRU files; since they now persist longer, we require more infrastructure to figure out when they can be removed. pg_upgrade also needs to be careful to copy pg_multixact files over from the old server to the new, or at least part of multixact.c state, depending on the versions of the old and new servers. Tuple time qualification rules (HeapTupleSatisfies routines) need to be careful not to consider tuples with the "is multi" infomask bit set as being only locked; they might need to look up MultiXact values (i.e. possibly do pg_multixact I/O) to find out the Xid that updated a tuple, whereas they previously were assured to only use information readily available from the tuple header. This is considered acceptable, because the extra I/O would involve cases that would previously cause some commands to block waiting for concurrent transactions to finish. Another important change is the fact that locking tuples that have previously been updated causes the future versions to be marked as locked, too; this is essential for correctness of foreign key checks. This causes additional WAL-logging, also (there was previously a single WAL record for a locked tuple; now there are as many as updated copies of the tuple there exist.) With all this in place, contention related to tuples being checked by foreign key rules should be much reduced. As a bonus, the old behavior that a subtransaction grabbing a stronger tuple lock than the parent (sub)transaction held on a given tuple and later aborting caused the weaker lock to be lost, has been fixed. Many new spec files were added for isolation tester framework, to ensure overall behavior is sane. There's probably room for several more tests. There were several reviewers of this patch; in particular, Noah Misch and Andres Freund spent considerable time in it. Original idea for the patch came from Simon Riggs, after a problem report by Joel Jacobson. Most code is from me, with contributions from Marti Raudsepp, Alexander Shulgin, Noah Misch and Andres Freund. This patch was discussed in several pgsql-hackers threads; the most important start at the following message-ids: AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com 1290721684-sup-3951@alvh.no-ip.org 1294953201-sup-2099@alvh.no-ip.org 1320343602-sup-2290@alvh.no-ip.org 1339690386-sup-8927@alvh.no-ip.org 4FE5FF020200002500048A3D@gw.wicourts.gov 4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 10:04:59 -05:00
*/
static inline Datum
MultiXactIdGetDatum(MultiXactId X)
{
return (Datum) X;
}
Improve concurrency of foreign key locking This patch introduces two additional lock modes for tuples: "SELECT FOR KEY SHARE" and "SELECT FOR NO KEY UPDATE". These don't block each other, in contrast with already existing "SELECT FOR SHARE" and "SELECT FOR UPDATE". UPDATE commands that do not modify the values stored in the columns that are part of the key of the tuple now grab a SELECT FOR NO KEY UPDATE lock on the tuple, allowing them to proceed concurrently with tuple locks of the FOR KEY SHARE variety. Foreign key triggers now use FOR KEY SHARE instead of FOR SHARE; this means the concurrency improvement applies to them, which is the whole point of this patch. The added tuple lock semantics require some rejiggering of the multixact module, so that the locking level that each transaction is holding can be stored alongside its Xid. Also, multixacts now need to persist across server restarts and crashes, because they can now represent not only tuple locks, but also tuple updates. This means we need more careful tracking of lifetime of pg_multixact SLRU files; since they now persist longer, we require more infrastructure to figure out when they can be removed. pg_upgrade also needs to be careful to copy pg_multixact files over from the old server to the new, or at least part of multixact.c state, depending on the versions of the old and new servers. Tuple time qualification rules (HeapTupleSatisfies routines) need to be careful not to consider tuples with the "is multi" infomask bit set as being only locked; they might need to look up MultiXact values (i.e. possibly do pg_multixact I/O) to find out the Xid that updated a tuple, whereas they previously were assured to only use information readily available from the tuple header. This is considered acceptable, because the extra I/O would involve cases that would previously cause some commands to block waiting for concurrent transactions to finish. Another important change is the fact that locking tuples that have previously been updated causes the future versions to be marked as locked, too; this is essential for correctness of foreign key checks. This causes additional WAL-logging, also (there was previously a single WAL record for a locked tuple; now there are as many as updated copies of the tuple there exist.) With all this in place, contention related to tuples being checked by foreign key rules should be much reduced. As a bonus, the old behavior that a subtransaction grabbing a stronger tuple lock than the parent (sub)transaction held on a given tuple and later aborting caused the weaker lock to be lost, has been fixed. Many new spec files were added for isolation tester framework, to ensure overall behavior is sane. There's probably room for several more tests. There were several reviewers of this patch; in particular, Noah Misch and Andres Freund spent considerable time in it. Original idea for the patch came from Simon Riggs, after a problem report by Joel Jacobson. Most code is from me, with contributions from Marti Raudsepp, Alexander Shulgin, Noah Misch and Andres Freund. This patch was discussed in several pgsql-hackers threads; the most important start at the following message-ids: AANLkTimo9XVcEzfiBR-ut3KVNDkjm2Vxh+t8kAmWjPuv@mail.gmail.com 1290721684-sup-3951@alvh.no-ip.org 1294953201-sup-2099@alvh.no-ip.org 1320343602-sup-2290@alvh.no-ip.org 1339690386-sup-8927@alvh.no-ip.org 4FE5FF020200002500048A3D@gw.wicourts.gov 4FEAB90A0200002500048B7D@gw.wicourts.gov
2013-01-23 10:04:59 -05:00
/*
* DatumGetCommandId
* Returns command identifier value of a datum.
*/
static inline CommandId
DatumGetCommandId(Datum X)
{
return (CommandId) X;
}
/*
* CommandIdGetDatum
* Returns datum representation for a command identifier.
*/
static inline Datum
CommandIdGetDatum(CommandId X)
{
return (Datum) X;
}
/*
* DatumGetPointer
* Returns pointer value of a datum.
*/
static inline Pointer
DatumGetPointer(Datum X)
{
Make type Datum be 8 bytes wide everywhere. This patch makes sizeof(Datum) be 8 on all platforms including 32-bit ones. The objective is to allow USE_FLOAT8_BYVAL to be true everywhere, and in consequence to remove a lot of code that is specific to pass-by-reference handling of float8, int8, etc. The code for abbreviated sort keys can be simplified similarly. In this way we can reduce the maintenance effort involved in supporting 32-bit platforms, without going so far as to actually desupport them. Since Datum is strictly an in-memory concept, this has no impact on on-disk storage, though an initdb or pg_upgrade will be needed to fix affected catalog entries. We have required platforms to support [u]int64 for ages, so this breaks no supported platform. We can expect that this change will make 32-bit builds a bit slower and more memory-hungry, although being able to use pass-by-value handling of 8-byte types may buy back some of that. But we stopped optimizing for 32-bit cases a long time ago, and this seems like just another step on that path. This initial patch simply forces the correct type definition and USE_FLOAT8_BYVAL setting, and cleans up a couple of minor compiler complaints that ensued. This is sufficient for testing purposes. In the wake of a bunch of Datum-conversion cleanups by Peter Eisentraut, this now compiles cleanly with gcc on a 32-bit platform. (I'd only tested the previous version with clang, which it turns out is less picky than gcc about width-changing coercions.) There is a good deal of now-dead code that I'll remove in separate follow-up patches. A catversion bump is required because this affects initial catalog contents (on 32-bit machines) in two ways: pg_type.typbyval changes for some built-in types, and Const nodes in stored views/rules will now have 8 bytes not 4 for pass-by-value types. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Discussion: https://postgr.es/m/1749799.1752797397@sss.pgh.pa.us
2025-08-13 16:35:06 -04:00
return (Pointer) (uintptr_t) X;
}
/*
* PointerGetDatum
* Returns datum representation for a pointer.
*/
static inline Datum
PointerGetDatum(const void *X)
{
Make type Datum be 8 bytes wide everywhere. This patch makes sizeof(Datum) be 8 on all platforms including 32-bit ones. The objective is to allow USE_FLOAT8_BYVAL to be true everywhere, and in consequence to remove a lot of code that is specific to pass-by-reference handling of float8, int8, etc. The code for abbreviated sort keys can be simplified similarly. In this way we can reduce the maintenance effort involved in supporting 32-bit platforms, without going so far as to actually desupport them. Since Datum is strictly an in-memory concept, this has no impact on on-disk storage, though an initdb or pg_upgrade will be needed to fix affected catalog entries. We have required platforms to support [u]int64 for ages, so this breaks no supported platform. We can expect that this change will make 32-bit builds a bit slower and more memory-hungry, although being able to use pass-by-value handling of 8-byte types may buy back some of that. But we stopped optimizing for 32-bit cases a long time ago, and this seems like just another step on that path. This initial patch simply forces the correct type definition and USE_FLOAT8_BYVAL setting, and cleans up a couple of minor compiler complaints that ensued. This is sufficient for testing purposes. In the wake of a bunch of Datum-conversion cleanups by Peter Eisentraut, this now compiles cleanly with gcc on a 32-bit platform. (I'd only tested the previous version with clang, which it turns out is less picky than gcc about width-changing coercions.) There is a good deal of now-dead code that I'll remove in separate follow-up patches. A catversion bump is required because this affects initial catalog contents (on 32-bit machines) in two ways: pg_type.typbyval changes for some built-in types, and Const nodes in stored views/rules will now have 8 bytes not 4 for pass-by-value types. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Discussion: https://postgr.es/m/1749799.1752797397@sss.pgh.pa.us
2025-08-13 16:35:06 -04:00
return (Datum) (uintptr_t) X;
}
/*
* DatumGetCString
* Returns C string (null-terminated string) value of a datum.
*
* Note: C string is not a full-fledged Postgres type at present,
* but type input functions use this conversion for their inputs.
*/
static inline char *
DatumGetCString(Datum X)
{
return (char *) DatumGetPointer(X);
}
/*
* CStringGetDatum
* Returns datum representation for a C string (null-terminated string).
*
* Note: C string is not a full-fledged Postgres type at present,
* but type output functions use this conversion for their outputs.
* Note: CString is pass-by-reference; caller must ensure the pointed-to
* value has adequate lifetime.
*/
static inline Datum
CStringGetDatum(const char *X)
{
return PointerGetDatum(X);
}
/*
* DatumGetName
* Returns name value of a datum.
*/
static inline Name
DatumGetName(Datum X)
{
return (Name) DatumGetPointer(X);
}
/*
* NameGetDatum
* Returns datum representation for a name.
*
* Note: Name is pass-by-reference; caller must ensure the pointed-to
* value has adequate lifetime.
*/
static inline Datum
NameGetDatum(const NameData *X)
{
return CStringGetDatum(NameStr(*X));
}
/*
* DatumGetInt64
* Returns 64-bit integer value of a datum.
*/
static inline int64
DatumGetInt64(Datum X)
{
return (int64) X;
}
/*
* Int64GetDatum
* Returns datum representation for a 64-bit integer.
*/
static inline Datum
Int64GetDatum(int64 X)
{
return (Datum) X;
}
/*
* DatumGetUInt64
* Returns 64-bit unsigned integer value of a datum.
*/
static inline uint64
DatumGetUInt64(Datum X)
{
return (uint64) X;
}
/*
* UInt64GetDatum
* Returns datum representation for a 64-bit unsigned integer.
*/
static inline Datum
UInt64GetDatum(uint64 X)
{
return (Datum) X;
}
/*
* Float <-> Datum conversions
*
* These have to be implemented as inline functions rather than macros, when
* passing by value, because many machines pass int and float function
* parameters/results differently; so we need to play weird games with unions.
*/
/*
* DatumGetFloat4
* Returns 4-byte floating point value of a datum.
*/
static inline float4
DatumGetFloat4(Datum X)
{
union
{
int32 value;
float4 retval;
} myunion;
myunion.value = DatumGetInt32(X);
return myunion.retval;
}
/*
* Float4GetDatum
* Returns datum representation for a 4-byte floating point number.
*/
static inline Datum
Float4GetDatum(float4 X)
{
union
{
float4 value;
int32 retval;
} myunion;
myunion.value = X;
return Int32GetDatum(myunion.retval);
}
/*
* DatumGetFloat8
* Returns 8-byte floating point value of a datum.
*/
static inline float8
DatumGetFloat8(Datum X)
{
union
{
int64 value;
float8 retval;
} myunion;
myunion.value = DatumGetInt64(X);
return myunion.retval;
}
/*
* Float8GetDatum
* Returns datum representation for an 8-byte floating point number.
*/
static inline Datum
Float8GetDatum(float8 X)
{
union
{
float8 value;
int64 retval;
} myunion;
myunion.value = X;
return Int64GetDatum(myunion.retval);
}
/*
* Int64GetDatumFast
* Float8GetDatumFast
*
* These macros were intended to allow writing code that does not depend on
* whether int64 and float8 are pass-by-reference types, while not
* sacrificing performance when they are. They are no longer different
* from the regular functions, though we keep the assertions to protect
* code that might get back-patched into older branches.
*/
#define Int64GetDatumFast(X) \
(StaticAssertVariableIsOfTypeMacro(X, int64), Int64GetDatum(X))
#define Float8GetDatumFast(X) \
(StaticAssertVariableIsOfTypeMacro(X, double), Float8GetDatum(X))
/* ----------------------------------------------------------------
* Section 2: miscellaneous
* ----------------------------------------------------------------
*/
/*
* pg_ternary
* Boolean value with an extra "unset" value
*
* This enum can be used for values that want to distinguish between true,
* false, and unset.
*/
typedef enum pg_ternary
{
PG_TERNARY_FALSE = 0,
PG_TERNARY_TRUE = 1,
PG_TERNARY_UNSET = -1
} pg_ternary;
/*
* NON_EXEC_STATIC: It's sometimes useful to define a variable or function
* that is normally static but extern when using EXEC_BACKEND (see
* pg_config_manual.h). There would then typically be some code in
* postmaster.c that uses those extern symbols to transfer state between
* processes or do whatever other things it needs to do in EXEC_BACKEND mode.
*/
#ifdef EXEC_BACKEND
#define NON_EXEC_STATIC
#else
#define NON_EXEC_STATIC static
#endif
Phase 2 of pgindent updates. Change pg_bsd_indent to follow upstream rules for placement of comments to the right of code, and remove pgindent hack that caused comments following #endif to not obey the general rule. Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using the published version of pg_bsd_indent, but a hacked-up version that tried to minimize the amount of movement of comments to the right of code. The situation of interest is where such a comment has to be moved to the right of its default placement at column 33 because there's code there. BSD indent has always moved right in units of tab stops in such cases --- but in the previous incarnation, indent was working in 8-space tab stops, while now it knows we use 4-space tabs. So the net result is that in about half the cases, such comments are placed one tab stop left of before. This is better all around: it leaves more room on the line for comment text, and it means that in such cases the comment uniformly starts at the next 4-space tab stop after the code, rather than sometimes one and sometimes two tabs after. Also, ensure that comments following #endif are indented the same as comments following other preprocessor commands such as #else. That inconsistency turns out to have been self-inflicted damage from a poorly-thought-through post-indent "fixup" in pgindent. This patch is much less interesting than the first round of indent changes, but also bulkier, so I thought it best to separate the effects. Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 15:18:54 -04:00
#endif /* POSTGRES_H */