1996-10-31 08:10:14 +01:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* postgres.h
|
2001-02-10 03:31:31 +01:00
|
|
|
* 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 08:10:14 +01:00
|
|
|
*
|
2019-01-02 18:44:25 +01:00
|
|
|
* Portions Copyright (c) 1996-2019, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1995, Regents of the University of California
|
1996-10-31 08:10:14 +01:00
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/include/postgres.h
|
1996-10-31 08:10:14 +01:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
/*
|
2001-02-10 03:31:31 +01:00
|
|
|
*----------------------------------------------------------------
|
|
|
|
* TABLE OF CONTENTS
|
1996-10-31 08:10:14 +01:00
|
|
|
*
|
2001-02-10 03:31:31 +01: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 08:10:14 +01:00
|
|
|
*
|
2001-02-10 03:31:31 +01:00
|
|
|
* section description
|
|
|
|
* ------- ------------------------------------------------
|
|
|
|
* 1) variable-length datatypes (TOAST support)
|
2018-01-23 17:19:12 +01:00
|
|
|
* 2) Datum type + support macros
|
1996-10-31 08:10:14 +01:00
|
|
|
*
|
2001-02-10 03:31:31 +01:00
|
|
|
* NOTES
|
|
|
|
*
|
2002-08-25 19:20:01 +02:00
|
|
|
* In general, this file should contain declarations that are widely needed
|
|
|
|
* in the backend environment, but are of no interest outside the backend.
|
2001-02-10 03:31:31 +01:00
|
|
|
*
|
2002-08-25 19:20:01 +02:00
|
|
|
* Simple type definitions live in c.h, where they are shared with
|
2014-05-06 18:12:18 +02:00
|
|
|
* postgres_fe.h. We do that since those type definitions are needed by
|
2002-08-25 19:20:01 +02:00
|
|
|
* 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 or
|
|
|
|
* TOASTed varlena objects.
|
2001-02-10 03:31:31 +01:00
|
|
|
*
|
|
|
|
*----------------------------------------------------------------
|
1996-10-31 08:10:14 +01:00
|
|
|
*/
|
|
|
|
#ifndef POSTGRES_H
|
|
|
|
#define POSTGRES_H
|
|
|
|
|
|
|
|
#include "c.h"
|
1999-07-15 17:21:54 +02:00
|
|
|
#include "utils/elog.h"
|
1999-07-16 19:07:40 +02:00
|
|
|
#include "utils/palloc.h"
|
1996-10-31 08:10:14 +01:00
|
|
|
|
|
|
|
/* ----------------------------------------------------------------
|
2001-02-10 03:31:31 +01:00
|
|
|
* Section 1: variable-length datatypes (TOAST support)
|
1996-10-31 08:10:14 +01:00
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
2007-04-06 06:21:44 +02:00
|
|
|
/*
|
2015-02-09 18:30:52 +01:00
|
|
|
* struct varatt_external is a traditional "TOAST pointer", that is, the
|
|
|
|
* information needed to fetch a Datum stored out-of-line in a TOAST table.
|
|
|
|
* The data is compressed if and only if va_extsize < va_rawsize - VARHDRSZ.
|
|
|
|
* This struct must not contain any padding, because we sometimes compare
|
|
|
|
* these pointers using memcmp.
|
2007-04-06 06:21:44 +02:00
|
|
|
*
|
|
|
|
* Note that this information is stored unaligned within actual tuples, so
|
|
|
|
* you need to memcpy from the tuple into a local struct variable before
|
|
|
|
* you can look at these fields! (The reason we use memcmp is to avoid
|
|
|
|
* having to do that just to detect equality of two TOAST pointers...)
|
|
|
|
*/
|
2013-07-02 19:35:14 +02:00
|
|
|
typedef struct varatt_external
|
2007-04-06 06:21:44 +02:00
|
|
|
{
|
2007-11-15 22:14:46 +01:00
|
|
|
int32 va_rawsize; /* Original data size (includes header) */
|
|
|
|
int32 va_extsize; /* External saved size (doesn't) */
|
|
|
|
Oid va_valueid; /* Unique ID of value within TOAST table */
|
|
|
|
Oid va_toastrelid; /* RelID of TOAST table containing it */
|
2017-06-21 20:39:04 +02:00
|
|
|
} varatt_external;
|
2013-07-02 19:35:14 +02:00
|
|
|
|
|
|
|
/*
|
2015-02-09 18:30:52 +01:00
|
|
|
* struct varatt_indirect is a "TOAST pointer" representing an out-of-line
|
|
|
|
* Datum that's stored in memory, not in an external toast relation.
|
|
|
|
* The creator of such a Datum is entirely responsible that the referenced
|
|
|
|
* storage survives for as long as referencing pointer Datums can exist.
|
2013-07-02 19:35:14 +02:00
|
|
|
*
|
2015-02-09 18:30:52 +01:00
|
|
|
* Note that just as for struct varatt_external, this struct is stored
|
|
|
|
* unaligned within any containing tuple.
|
2013-07-02 19:35:14 +02:00
|
|
|
*/
|
|
|
|
typedef struct varatt_indirect
|
|
|
|
{
|
|
|
|
struct varlena *pointer; /* Pointer to in-memory varlena */
|
2017-06-21 20:39:04 +02:00
|
|
|
} varatt_indirect;
|
2013-07-02 19:35:14 +02:00
|
|
|
|
Support "expanded" objects, particularly arrays, for better performance.
This patch introduces the ability for complex datatypes to have an
in-memory representation that is different from their on-disk format.
On-disk formats are typically optimized for minimal size, and in any case
they can't contain pointers, so they are often not well-suited for
computation. Now a datatype can invent an "expanded" in-memory format
that is better suited for its operations, and then pass that around among
the C functions that operate on the datatype. There are also provisions
(rudimentary as yet) to allow an expanded object to be modified in-place
under suitable conditions, so that operations like assignment to an element
of an array need not involve copying the entire array.
The initial application for this feature is arrays, but it is not hard
to foresee using it for other container types like JSON, XML and hstore.
I have hopes that it will be useful to PostGIS as well.
In this initial implementation, a few heuristics have been hard-wired
into plpgsql to improve performance for arrays that are stored in
plpgsql variables. We would like to generalize those hacks so that
other datatypes can obtain similar improvements, but figuring out some
appropriate APIs is left as a task for future work. (The heuristics
themselves are probably not optimal yet, either, as they sometimes
force expansion of arrays that would be better left alone.)
Preliminary performance testing shows impressive speed gains for plpgsql
functions that do element-by-element access or update of large arrays.
There are other cases that get a little slower, as a result of added array
format conversions; but we can hope to improve anything that's annoyingly
bad. In any case most applications should see a net win.
Tom Lane, reviewed by Andres Freund
2015-05-14 18:08:40 +02:00
|
|
|
/*
|
|
|
|
* struct varatt_expanded is a "TOAST pointer" representing an out-of-line
|
|
|
|
* Datum that is stored in memory, in some type-specific, not necessarily
|
|
|
|
* physically contiguous format that is convenient for computation not
|
|
|
|
* storage. APIs for this, in particular the definition of struct
|
|
|
|
* ExpandedObjectHeader, are in src/include/utils/expandeddatum.h.
|
|
|
|
*
|
|
|
|
* Note that just as for struct varatt_external, this struct is stored
|
|
|
|
* unaligned within any containing tuple.
|
|
|
|
*/
|
|
|
|
typedef struct ExpandedObjectHeader ExpandedObjectHeader;
|
|
|
|
|
|
|
|
typedef struct varatt_expanded
|
|
|
|
{
|
|
|
|
ExpandedObjectHeader *eohptr;
|
|
|
|
} varatt_expanded;
|
|
|
|
|
2013-07-02 19:35:14 +02:00
|
|
|
/*
|
2015-02-09 18:30:52 +01:00
|
|
|
* Type tag for the various sorts of "TOAST pointer" datums. The peculiar
|
|
|
|
* value for VARTAG_ONDISK comes from a requirement for on-disk compatibility
|
|
|
|
* with a previous notion that the tag field was the pointer datum's length.
|
2013-07-02 19:35:14 +02:00
|
|
|
*/
|
|
|
|
typedef enum vartag_external
|
|
|
|
{
|
|
|
|
VARTAG_INDIRECT = 1,
|
Support "expanded" objects, particularly arrays, for better performance.
This patch introduces the ability for complex datatypes to have an
in-memory representation that is different from their on-disk format.
On-disk formats are typically optimized for minimal size, and in any case
they can't contain pointers, so they are often not well-suited for
computation. Now a datatype can invent an "expanded" in-memory format
that is better suited for its operations, and then pass that around among
the C functions that operate on the datatype. There are also provisions
(rudimentary as yet) to allow an expanded object to be modified in-place
under suitable conditions, so that operations like assignment to an element
of an array need not involve copying the entire array.
The initial application for this feature is arrays, but it is not hard
to foresee using it for other container types like JSON, XML and hstore.
I have hopes that it will be useful to PostGIS as well.
In this initial implementation, a few heuristics have been hard-wired
into plpgsql to improve performance for arrays that are stored in
plpgsql variables. We would like to generalize those hacks so that
other datatypes can obtain similar improvements, but figuring out some
appropriate APIs is left as a task for future work. (The heuristics
themselves are probably not optimal yet, either, as they sometimes
force expansion of arrays that would be better left alone.)
Preliminary performance testing shows impressive speed gains for plpgsql
functions that do element-by-element access or update of large arrays.
There are other cases that get a little slower, as a result of added array
format conversions; but we can hope to improve anything that's annoyingly
bad. In any case most applications should see a net win.
Tom Lane, reviewed by Andres Freund
2015-05-14 18:08:40 +02:00
|
|
|
VARTAG_EXPANDED_RO = 2,
|
|
|
|
VARTAG_EXPANDED_RW = 3,
|
2013-07-02 19:35:14 +02:00
|
|
|
VARTAG_ONDISK = 18
|
|
|
|
} vartag_external;
|
|
|
|
|
Support "expanded" objects, particularly arrays, for better performance.
This patch introduces the ability for complex datatypes to have an
in-memory representation that is different from their on-disk format.
On-disk formats are typically optimized for minimal size, and in any case
they can't contain pointers, so they are often not well-suited for
computation. Now a datatype can invent an "expanded" in-memory format
that is better suited for its operations, and then pass that around among
the C functions that operate on the datatype. There are also provisions
(rudimentary as yet) to allow an expanded object to be modified in-place
under suitable conditions, so that operations like assignment to an element
of an array need not involve copying the entire array.
The initial application for this feature is arrays, but it is not hard
to foresee using it for other container types like JSON, XML and hstore.
I have hopes that it will be useful to PostGIS as well.
In this initial implementation, a few heuristics have been hard-wired
into plpgsql to improve performance for arrays that are stored in
plpgsql variables. We would like to generalize those hacks so that
other datatypes can obtain similar improvements, but figuring out some
appropriate APIs is left as a task for future work. (The heuristics
themselves are probably not optimal yet, either, as they sometimes
force expansion of arrays that would be better left alone.)
Preliminary performance testing shows impressive speed gains for plpgsql
functions that do element-by-element access or update of large arrays.
There are other cases that get a little slower, as a result of added array
format conversions; but we can hope to improve anything that's annoyingly
bad. In any case most applications should see a net win.
Tom Lane, reviewed by Andres Freund
2015-05-14 18:08:40 +02:00
|
|
|
/* this test relies on the specific tag values above */
|
|
|
|
#define VARTAG_IS_EXPANDED(tag) \
|
|
|
|
(((tag) & ~1) == VARTAG_EXPANDED_RO)
|
|
|
|
|
2013-07-02 19:35:14 +02:00
|
|
|
#define VARTAG_SIZE(tag) \
|
2015-02-09 18:30:52 +01:00
|
|
|
((tag) == VARTAG_INDIRECT ? sizeof(varatt_indirect) : \
|
Support "expanded" objects, particularly arrays, for better performance.
This patch introduces the ability for complex datatypes to have an
in-memory representation that is different from their on-disk format.
On-disk formats are typically optimized for minimal size, and in any case
they can't contain pointers, so they are often not well-suited for
computation. Now a datatype can invent an "expanded" in-memory format
that is better suited for its operations, and then pass that around among
the C functions that operate on the datatype. There are also provisions
(rudimentary as yet) to allow an expanded object to be modified in-place
under suitable conditions, so that operations like assignment to an element
of an array need not involve copying the entire array.
The initial application for this feature is arrays, but it is not hard
to foresee using it for other container types like JSON, XML and hstore.
I have hopes that it will be useful to PostGIS as well.
In this initial implementation, a few heuristics have been hard-wired
into plpgsql to improve performance for arrays that are stored in
plpgsql variables. We would like to generalize those hacks so that
other datatypes can obtain similar improvements, but figuring out some
appropriate APIs is left as a task for future work. (The heuristics
themselves are probably not optimal yet, either, as they sometimes
force expansion of arrays that would be better left alone.)
Preliminary performance testing shows impressive speed gains for plpgsql
functions that do element-by-element access or update of large arrays.
There are other cases that get a little slower, as a result of added array
format conversions; but we can hope to improve anything that's annoyingly
bad. In any case most applications should see a net win.
Tom Lane, reviewed by Andres Freund
2015-05-14 18:08:40 +02:00
|
|
|
VARTAG_IS_EXPANDED(tag) ? sizeof(varatt_expanded) : \
|
2013-07-02 19:35:14 +02:00
|
|
|
(tag) == VARTAG_ONDISK ? sizeof(varatt_external) : \
|
2015-02-09 18:30:52 +01:00
|
|
|
TrapMacro(true, "unrecognized TOAST vartag"))
|
2007-04-06 06:21:44 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* These structs describe the header of a varlena object that may have been
|
|
|
|
* TOASTed. Generally, don't reference these structs directly, but use the
|
|
|
|
* macros below.
|
|
|
|
*
|
|
|
|
* We use separate structs for the aligned and unaligned cases because the
|
|
|
|
* compiler might otherwise think it could generate code that assumes
|
|
|
|
* alignment while touching fields of a 1-byte-header varlena.
|
1996-10-31 08:10:14 +01:00
|
|
|
*/
|
2007-04-06 06:21:44 +02:00
|
|
|
typedef union
|
1999-12-21 01:06:44 +01:00
|
|
|
{
|
2007-11-15 22:14:46 +01:00
|
|
|
struct /* Normal varlena (4-byte length) */
|
2007-04-06 06:21:44 +02:00
|
|
|
{
|
2007-11-15 22:14:46 +01:00
|
|
|
uint32 va_header;
|
2015-02-20 06:11:42 +01:00
|
|
|
char va_data[FLEXIBLE_ARRAY_MEMBER];
|
2007-11-15 22:14:46 +01:00
|
|
|
} va_4byte;
|
|
|
|
struct /* Compressed-in-line format */
|
1999-12-21 01:06:44 +01:00
|
|
|
{
|
2007-11-15 22:14:46 +01:00
|
|
|
uint32 va_header;
|
|
|
|
uint32 va_rawsize; /* Original data size (excludes header) */
|
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 21:18:54 +02:00
|
|
|
char va_data[FLEXIBLE_ARRAY_MEMBER]; /* Compressed data */
|
2007-11-15 22:14:46 +01:00
|
|
|
} va_compressed;
|
2007-11-15 23:25:18 +01:00
|
|
|
} varattrib_4b;
|
2007-04-06 06:21:44 +02:00
|
|
|
|
|
|
|
typedef struct
|
|
|
|
{
|
|
|
|
uint8 va_header;
|
2015-02-20 06:11:42 +01:00
|
|
|
char va_data[FLEXIBLE_ARRAY_MEMBER]; /* Data begins here */
|
2007-11-15 23:25:18 +01:00
|
|
|
} varattrib_1b;
|
2007-04-06 06:21:44 +02:00
|
|
|
|
2015-02-09 18:30:52 +01:00
|
|
|
/* TOAST pointers are a subset of varattrib_1b with an identifying tag byte */
|
2007-04-06 06:21:44 +02:00
|
|
|
typedef struct
|
|
|
|
{
|
2007-11-15 22:14:46 +01:00
|
|
|
uint8 va_header; /* Always 0x80 or 0x01 */
|
2013-07-02 19:35:14 +02:00
|
|
|
uint8 va_tag; /* Type of datum */
|
2015-02-20 06:11:42 +01:00
|
|
|
char va_data[FLEXIBLE_ARRAY_MEMBER]; /* Type-specific data */
|
2007-11-15 23:25:18 +01:00
|
|
|
} varattrib_1b_e;
|
2007-09-30 21:54:58 +02:00
|
|
|
|
2007-04-06 06:21:44 +02:00
|
|
|
/*
|
|
|
|
* Bit layouts for varlena headers on big-endian machines:
|
|
|
|
*
|
2007-11-15 22:14:46 +01:00
|
|
|
* 00xxxxxx 4-byte length word, aligned, uncompressed data (up to 1G)
|
|
|
|
* 01xxxxxx 4-byte length word, aligned, *compressed* data (up to 1G)
|
|
|
|
* 10000000 1-byte length word, unaligned, TOAST pointer
|
|
|
|
* 1xxxxxxx 1-byte length word, unaligned, uncompressed data (up to 126b)
|
2007-04-06 06:21:44 +02:00
|
|
|
*
|
|
|
|
* Bit layouts for varlena headers on little-endian machines:
|
|
|
|
*
|
2007-11-15 22:14:46 +01:00
|
|
|
* xxxxxx00 4-byte length word, aligned, uncompressed data (up to 1G)
|
|
|
|
* xxxxxx10 4-byte length word, aligned, *compressed* data (up to 1G)
|
|
|
|
* 00000001 1-byte length word, unaligned, TOAST pointer
|
|
|
|
* xxxxxxx1 1-byte length word, unaligned, uncompressed data (up to 126b)
|
2007-04-06 06:21:44 +02:00
|
|
|
*
|
|
|
|
* The "xxx" bits are the length field (which includes itself in all cases).
|
|
|
|
* In the big-endian case we mask to extract the length, in the little-endian
|
|
|
|
* case we shift. Note that in both cases the flag bits are in the physically
|
2014-05-06 18:12:18 +02:00
|
|
|
* first byte. Also, it is not possible for a 1-byte length word to be zero;
|
2007-04-06 06:21:44 +02:00
|
|
|
* this lets us disambiguate alignment padding bytes from the start of an
|
|
|
|
* unaligned datum. (We now *require* pad bytes to be filled with zero!)
|
2013-07-02 19:35:14 +02:00
|
|
|
*
|
2015-02-09 18:30:52 +01:00
|
|
|
* In TOAST pointers the va_tag field (see varattrib_1b_e) is used to discern
|
|
|
|
* the specific type and length of the pointer datum.
|
2007-04-06 06:21:44 +02:00
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Endian-dependent macros. These are considered internal --- use the
|
|
|
|
* external macros below instead of using these directly.
|
|
|
|
*
|
|
|
|
* Note: IS_1B is true for external toast records but VARSIZE_1B will return 0
|
|
|
|
* for such records. Hence you should usually check for IS_EXTERNAL before
|
|
|
|
* checking for IS_1B.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifdef WORDS_BIGENDIAN
|
|
|
|
|
|
|
|
#define VARATT_IS_4B(PTR) \
|
|
|
|
((((varattrib_1b *) (PTR))->va_header & 0x80) == 0x00)
|
|
|
|
#define VARATT_IS_4B_U(PTR) \
|
|
|
|
((((varattrib_1b *) (PTR))->va_header & 0xC0) == 0x00)
|
|
|
|
#define VARATT_IS_4B_C(PTR) \
|
|
|
|
((((varattrib_1b *) (PTR))->va_header & 0xC0) == 0x40)
|
|
|
|
#define VARATT_IS_1B(PTR) \
|
|
|
|
((((varattrib_1b *) (PTR))->va_header & 0x80) == 0x80)
|
|
|
|
#define VARATT_IS_1B_E(PTR) \
|
|
|
|
((((varattrib_1b *) (PTR))->va_header) == 0x80)
|
|
|
|
#define VARATT_NOT_PAD_BYTE(PTR) \
|
|
|
|
(*((uint8 *) (PTR)) != 0)
|
|
|
|
|
|
|
|
/* VARSIZE_4B() should only be used on known-aligned data */
|
|
|
|
#define VARSIZE_4B(PTR) \
|
|
|
|
(((varattrib_4b *) (PTR))->va_4byte.va_header & 0x3FFFFFFF)
|
|
|
|
#define VARSIZE_1B(PTR) \
|
|
|
|
(((varattrib_1b *) (PTR))->va_header & 0x7F)
|
2013-07-02 19:35:14 +02:00
|
|
|
#define VARTAG_1B_E(PTR) \
|
|
|
|
(((varattrib_1b_e *) (PTR))->va_tag)
|
2007-04-06 06:21:44 +02:00
|
|
|
|
|
|
|
#define SET_VARSIZE_4B(PTR,len) \
|
|
|
|
(((varattrib_4b *) (PTR))->va_4byte.va_header = (len) & 0x3FFFFFFF)
|
|
|
|
#define SET_VARSIZE_4B_C(PTR,len) \
|
|
|
|
(((varattrib_4b *) (PTR))->va_4byte.va_header = ((len) & 0x3FFFFFFF) | 0x40000000)
|
|
|
|
#define SET_VARSIZE_1B(PTR,len) \
|
|
|
|
(((varattrib_1b *) (PTR))->va_header = (len) | 0x80)
|
2013-07-02 19:35:14 +02:00
|
|
|
#define SET_VARTAG_1B_E(PTR,tag) \
|
2007-09-30 21:54:58 +02:00
|
|
|
(((varattrib_1b_e *) (PTR))->va_header = 0x80, \
|
2013-07-02 19:35:14 +02:00
|
|
|
((varattrib_1b_e *) (PTR))->va_tag = (tag))
|
2007-11-15 22:14:46 +01:00
|
|
|
#else /* !WORDS_BIGENDIAN */
|
2007-04-06 06:21:44 +02:00
|
|
|
|
|
|
|
#define VARATT_IS_4B(PTR) \
|
|
|
|
((((varattrib_1b *) (PTR))->va_header & 0x01) == 0x00)
|
|
|
|
#define VARATT_IS_4B_U(PTR) \
|
|
|
|
((((varattrib_1b *) (PTR))->va_header & 0x03) == 0x00)
|
|
|
|
#define VARATT_IS_4B_C(PTR) \
|
|
|
|
((((varattrib_1b *) (PTR))->va_header & 0x03) == 0x02)
|
|
|
|
#define VARATT_IS_1B(PTR) \
|
|
|
|
((((varattrib_1b *) (PTR))->va_header & 0x01) == 0x01)
|
|
|
|
#define VARATT_IS_1B_E(PTR) \
|
|
|
|
((((varattrib_1b *) (PTR))->va_header) == 0x01)
|
|
|
|
#define VARATT_NOT_PAD_BYTE(PTR) \
|
|
|
|
(*((uint8 *) (PTR)) != 0)
|
|
|
|
|
|
|
|
/* VARSIZE_4B() should only be used on known-aligned data */
|
|
|
|
#define VARSIZE_4B(PTR) \
|
|
|
|
((((varattrib_4b *) (PTR))->va_4byte.va_header >> 2) & 0x3FFFFFFF)
|
|
|
|
#define VARSIZE_1B(PTR) \
|
|
|
|
((((varattrib_1b *) (PTR))->va_header >> 1) & 0x7F)
|
2013-07-02 19:35:14 +02:00
|
|
|
#define VARTAG_1B_E(PTR) \
|
|
|
|
(((varattrib_1b_e *) (PTR))->va_tag)
|
2007-04-06 06:21:44 +02:00
|
|
|
|
|
|
|
#define SET_VARSIZE_4B(PTR,len) \
|
|
|
|
(((varattrib_4b *) (PTR))->va_4byte.va_header = (((uint32) (len)) << 2))
|
|
|
|
#define SET_VARSIZE_4B_C(PTR,len) \
|
|
|
|
(((varattrib_4b *) (PTR))->va_4byte.va_header = (((uint32) (len)) << 2) | 0x02)
|
|
|
|
#define SET_VARSIZE_1B(PTR,len) \
|
|
|
|
(((varattrib_1b *) (PTR))->va_header = (((uint8) (len)) << 1) | 0x01)
|
2013-07-02 19:35:14 +02:00
|
|
|
#define SET_VARTAG_1B_E(PTR,tag) \
|
2007-09-30 21:54:58 +02:00
|
|
|
(((varattrib_1b_e *) (PTR))->va_header = 0x01, \
|
2013-07-02 19:35:14 +02:00
|
|
|
((varattrib_1b_e *) (PTR))->va_tag = (tag))
|
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 21:18:54 +02:00
|
|
|
#endif /* WORDS_BIGENDIAN */
|
2007-04-06 06:21:44 +02:00
|
|
|
|
2013-07-02 19:35:14 +02:00
|
|
|
#define VARHDRSZ_SHORT offsetof(varattrib_1b, va_data)
|
2007-04-06 06:21:44 +02:00
|
|
|
#define VARATT_SHORT_MAX 0x7F
|
|
|
|
#define VARATT_CAN_MAKE_SHORT(PTR) \
|
|
|
|
(VARATT_IS_4B_U(PTR) && \
|
|
|
|
(VARSIZE(PTR) - VARHDRSZ + VARHDRSZ_SHORT) <= VARATT_SHORT_MAX)
|
|
|
|
#define VARATT_CONVERTED_SHORT_SIZE(PTR) \
|
|
|
|
(VARSIZE(PTR) - VARHDRSZ + VARHDRSZ_SHORT)
|
|
|
|
|
2013-07-02 19:35:14 +02:00
|
|
|
#define VARHDRSZ_EXTERNAL offsetof(varattrib_1b_e, va_data)
|
2007-10-01 18:25:56 +02:00
|
|
|
|
2007-04-06 06:21:44 +02:00
|
|
|
#define VARDATA_4B(PTR) (((varattrib_4b *) (PTR))->va_4byte.va_data)
|
|
|
|
#define VARDATA_4B_C(PTR) (((varattrib_4b *) (PTR))->va_compressed.va_data)
|
|
|
|
#define VARDATA_1B(PTR) (((varattrib_1b *) (PTR))->va_data)
|
2007-09-30 21:54:58 +02:00
|
|
|
#define VARDATA_1B_E(PTR) (((varattrib_1b_e *) (PTR))->va_data)
|
2007-04-06 06:21:44 +02:00
|
|
|
|
|
|
|
#define VARRAWSIZE_4B_C(PTR) \
|
|
|
|
(((varattrib_4b *) (PTR))->va_compressed.va_rawsize)
|
|
|
|
|
|
|
|
/* Externally visible macros */
|
|
|
|
|
|
|
|
/*
|
2017-03-13 00:35:33 +01:00
|
|
|
* In consumers oblivious to data alignment, call PG_DETOAST_DATUM_PACKED(),
|
|
|
|
* VARDATA_ANY(), VARSIZE_ANY() and VARSIZE_ANY_EXHDR(). Elsewhere, call
|
|
|
|
* PG_DETOAST_DATUM(), VARDATA() and VARSIZE(). Directly fetching an int16,
|
|
|
|
* int32 or wider field in the struct representing the datum layout requires
|
|
|
|
* aligned data. memcpy() is alignment-oblivious, as are most operations on
|
|
|
|
* datatypes, such as text, whose layout struct contains only char fields.
|
2007-04-06 06:21:44 +02:00
|
|
|
*
|
2017-03-13 00:35:33 +01:00
|
|
|
* Code assembling a new datum should call VARDATA() and SET_VARSIZE().
|
|
|
|
* (Datums begin life untoasted.)
|
2007-05-15 19:39:54 +02:00
|
|
|
*
|
2017-03-13 00:35:33 +01:00
|
|
|
* Other macros here should usually be used only by tuple assembly/disassembly
|
|
|
|
* code and code that specifically wants to work with still-toasted Datums.
|
2007-04-06 06:21:44 +02:00
|
|
|
*/
|
|
|
|
#define VARDATA(PTR) VARDATA_4B(PTR)
|
|
|
|
#define VARSIZE(PTR) VARSIZE_4B(PTR)
|
|
|
|
|
|
|
|
#define VARSIZE_SHORT(PTR) VARSIZE_1B(PTR)
|
|
|
|
#define VARDATA_SHORT(PTR) VARDATA_1B(PTR)
|
|
|
|
|
2013-07-02 19:35:14 +02:00
|
|
|
#define VARTAG_EXTERNAL(PTR) VARTAG_1B_E(PTR)
|
|
|
|
#define VARSIZE_EXTERNAL(PTR) (VARHDRSZ_EXTERNAL + VARTAG_SIZE(VARTAG_EXTERNAL(PTR)))
|
2007-09-30 21:54:58 +02:00
|
|
|
#define VARDATA_EXTERNAL(PTR) VARDATA_1B_E(PTR)
|
2007-04-06 06:21:44 +02:00
|
|
|
|
|
|
|
#define VARATT_IS_COMPRESSED(PTR) VARATT_IS_4B_C(PTR)
|
|
|
|
#define VARATT_IS_EXTERNAL(PTR) VARATT_IS_1B_E(PTR)
|
2013-07-02 19:35:14 +02:00
|
|
|
#define VARATT_IS_EXTERNAL_ONDISK(PTR) \
|
|
|
|
(VARATT_IS_EXTERNAL(PTR) && VARTAG_EXTERNAL(PTR) == VARTAG_ONDISK)
|
|
|
|
#define VARATT_IS_EXTERNAL_INDIRECT(PTR) \
|
|
|
|
(VARATT_IS_EXTERNAL(PTR) && VARTAG_EXTERNAL(PTR) == VARTAG_INDIRECT)
|
Support "expanded" objects, particularly arrays, for better performance.
This patch introduces the ability for complex datatypes to have an
in-memory representation that is different from their on-disk format.
On-disk formats are typically optimized for minimal size, and in any case
they can't contain pointers, so they are often not well-suited for
computation. Now a datatype can invent an "expanded" in-memory format
that is better suited for its operations, and then pass that around among
the C functions that operate on the datatype. There are also provisions
(rudimentary as yet) to allow an expanded object to be modified in-place
under suitable conditions, so that operations like assignment to an element
of an array need not involve copying the entire array.
The initial application for this feature is arrays, but it is not hard
to foresee using it for other container types like JSON, XML and hstore.
I have hopes that it will be useful to PostGIS as well.
In this initial implementation, a few heuristics have been hard-wired
into plpgsql to improve performance for arrays that are stored in
plpgsql variables. We would like to generalize those hacks so that
other datatypes can obtain similar improvements, but figuring out some
appropriate APIs is left as a task for future work. (The heuristics
themselves are probably not optimal yet, either, as they sometimes
force expansion of arrays that would be better left alone.)
Preliminary performance testing shows impressive speed gains for plpgsql
functions that do element-by-element access or update of large arrays.
There are other cases that get a little slower, as a result of added array
format conversions; but we can hope to improve anything that's annoyingly
bad. In any case most applications should see a net win.
Tom Lane, reviewed by Andres Freund
2015-05-14 18:08:40 +02:00
|
|
|
#define VARATT_IS_EXTERNAL_EXPANDED_RO(PTR) \
|
|
|
|
(VARATT_IS_EXTERNAL(PTR) && VARTAG_EXTERNAL(PTR) == VARTAG_EXPANDED_RO)
|
|
|
|
#define VARATT_IS_EXTERNAL_EXPANDED_RW(PTR) \
|
|
|
|
(VARATT_IS_EXTERNAL(PTR) && VARTAG_EXTERNAL(PTR) == VARTAG_EXPANDED_RW)
|
|
|
|
#define VARATT_IS_EXTERNAL_EXPANDED(PTR) \
|
|
|
|
(VARATT_IS_EXTERNAL(PTR) && VARTAG_IS_EXPANDED(VARTAG_EXTERNAL(PTR)))
|
Detoast plpgsql variables if they might live across a transaction boundary.
Up to now, it's been safe for plpgsql to store TOAST pointers in its
variables because the ActiveSnapshot for whatever query called the plpgsql
function will surely protect such TOAST values from being vacuumed away,
even if the owning table rows are committed dead. With the introduction of
procedures, that assumption is no longer good in "non atomic" executions
of plpgsql code. We adopt the slightly brute-force solution of detoasting
all TOAST pointers at the time they are stored into variables, if we're in
a non-atomic context, just in case the owning row goes away.
Some care is needed to avoid long-term memory leaks, since plpgsql tends
to run with CurrentMemoryContext pointing to its call-lifespan context,
but we shouldn't assume that no memory is leaked by heap_tuple_fetch_attr.
In plpgsql proper, we can do the detoasting work in the "eval_mcontext".
Most of the code thrashing here is due to the need to add this capability
to expandedrecord.c as well as plpgsql proper. In expandedrecord.c,
we can't assume that the caller's context is short-lived, so make use of
the short-term sub-context that was already invented for checking domain
constraints. In view of this repurposing, it seems good to rename that
variable and associated code from "domain_check_cxt" to "short_term_cxt".
Peter Eisentraut and Tom Lane
Discussion: https://postgr.es/m/5AC06865.9050005@anastigmatix.net
2018-05-16 20:56:52 +02:00
|
|
|
#define VARATT_IS_EXTERNAL_NON_EXPANDED(PTR) \
|
|
|
|
(VARATT_IS_EXTERNAL(PTR) && !VARTAG_IS_EXPANDED(VARTAG_EXTERNAL(PTR)))
|
2007-04-06 06:21:44 +02:00
|
|
|
#define VARATT_IS_SHORT(PTR) VARATT_IS_1B(PTR)
|
|
|
|
#define VARATT_IS_EXTENDED(PTR) (!VARATT_IS_4B_U(PTR))
|
|
|
|
|
|
|
|
#define SET_VARSIZE(PTR, len) SET_VARSIZE_4B(PTR, len)
|
|
|
|
#define SET_VARSIZE_SHORT(PTR, len) SET_VARSIZE_1B(PTR, len)
|
|
|
|
#define SET_VARSIZE_COMPRESSED(PTR, len) SET_VARSIZE_4B_C(PTR, len)
|
2013-07-02 19:35:14 +02:00
|
|
|
|
|
|
|
#define SET_VARTAG_EXTERNAL(PTR, tag) SET_VARTAG_1B_E(PTR, tag)
|
2007-04-06 06:21:44 +02:00
|
|
|
|
|
|
|
#define VARSIZE_ANY(PTR) \
|
2013-07-02 19:35:14 +02:00
|
|
|
(VARATT_IS_1B_E(PTR) ? VARSIZE_EXTERNAL(PTR) : \
|
2007-04-06 06:21:44 +02:00
|
|
|
(VARATT_IS_1B(PTR) ? VARSIZE_1B(PTR) : \
|
|
|
|
VARSIZE_4B(PTR)))
|
|
|
|
|
2013-09-11 02:18:53 +02:00
|
|
|
/* Size of a varlena data, excluding header */
|
2007-04-06 06:21:44 +02:00
|
|
|
#define VARSIZE_ANY_EXHDR(PTR) \
|
2013-07-02 19:35:14 +02:00
|
|
|
(VARATT_IS_1B_E(PTR) ? VARSIZE_EXTERNAL(PTR)-VARHDRSZ_EXTERNAL : \
|
2007-10-01 18:25:56 +02:00
|
|
|
(VARATT_IS_1B(PTR) ? VARSIZE_1B(PTR)-VARHDRSZ_SHORT : \
|
|
|
|
VARSIZE_4B(PTR)-VARHDRSZ))
|
2007-04-06 06:21:44 +02:00
|
|
|
|
|
|
|
/* caution: this will not work on an external or compressed-in-line Datum */
|
2007-05-15 19:39:54 +02:00
|
|
|
/* caution: this will return a possibly unaligned pointer */
|
2007-04-06 06:21:44 +02:00
|
|
|
#define VARDATA_ANY(PTR) \
|
|
|
|
(VARATT_IS_1B(PTR) ? VARDATA_1B(PTR) : VARDATA_4B(PTR))
|
1999-12-21 01:06:44 +01:00
|
|
|
|
2001-02-10 03:31:31 +01:00
|
|
|
|
|
|
|
/* ----------------------------------------------------------------
|
2018-01-23 17:19:12 +01:00
|
|
|
* Section 2: Datum type + support macros
|
2001-02-10 03:31:31 +01:00
|
|
|
* ----------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
2018-01-23 17:19:12 +01:00
|
|
|
* A Datum contains either a value of a pass-by-value type or a pointer to a
|
|
|
|
* value of a pass-by-reference type. Therefore, we require:
|
2001-02-10 03:31:31 +01:00
|
|
|
*
|
2018-01-23 17:19:12 +01:00
|
|
|
* sizeof(Datum) == sizeof(void *) == 4 or 8
|
2001-02-10 03:31:31 +01:00
|
|
|
*
|
2018-01-23 17:19:12 +01:00
|
|
|
* The macros below and the analogous macros for other types should be used to
|
|
|
|
* convert between a Datum and the appropriate C type.
|
2001-02-10 03:31:31 +01:00
|
|
|
*/
|
|
|
|
|
2009-12-31 20:41:37 +01:00
|
|
|
typedef uintptr_t Datum;
|
2003-08-04 02:43:34 +02: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 23:17:52 +01: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;
|
|
|
|
|
2009-12-31 20:41:37 +01:00
|
|
|
#define SIZEOF_DATUM SIZEOF_VOID_P
|
2007-03-23 21:24:41 +01:00
|
|
|
|
2001-02-10 03:31:31 +01:00
|
|
|
/*
|
|
|
|
* DatumGetBool
|
|
|
|
* Returns boolean value of a datum.
|
|
|
|
*
|
2018-01-23 17:19:12 +01:00
|
|
|
* Note: any nonzero value will be considered true.
|
1999-12-21 01:06:44 +01:00
|
|
|
*/
|
|
|
|
|
2018-01-23 17:19:12 +01:00
|
|
|
#define DatumGetBool(X) ((bool) ((X) != 0))
|
2001-02-10 03:31:31 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* BoolGetDatum
|
|
|
|
* Returns datum representation for a boolean.
|
|
|
|
*
|
2018-01-23 17:19:12 +01:00
|
|
|
* Note: any nonzero value will be considered true.
|
2001-02-10 03:31:31 +01:00
|
|
|
*/
|
1999-12-21 01:06:44 +01:00
|
|
|
|
2001-02-10 03:31:31 +01:00
|
|
|
#define BoolGetDatum(X) ((Datum) ((X) ? 1 : 0))
|
1999-12-21 01:06:44 +01:00
|
|
|
|
2001-02-10 03:31:31 +01:00
|
|
|
/*
|
|
|
|
* DatumGetChar
|
|
|
|
* Returns character value of a datum.
|
|
|
|
*/
|
2000-06-13 09:35:40 +02:00
|
|
|
|
2018-01-23 17:19:12 +01:00
|
|
|
#define DatumGetChar(X) ((char) (X))
|
2000-06-13 09:35:40 +02:00
|
|
|
|
2001-02-10 03:31:31 +01:00
|
|
|
/*
|
|
|
|
* CharGetDatum
|
|
|
|
* Returns datum representation for a character.
|
|
|
|
*/
|
|
|
|
|
2018-01-23 17:19:12 +01:00
|
|
|
#define CharGetDatum(X) ((Datum) (X))
|
2001-02-10 03:31:31 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Int8GetDatum
|
|
|
|
* Returns datum representation for an 8-bit integer.
|
|
|
|
*/
|
|
|
|
|
2018-01-23 17:19:12 +01:00
|
|
|
#define Int8GetDatum(X) ((Datum) (X))
|
2001-02-10 03:31:31 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* DatumGetUInt8
|
|
|
|
* Returns 8-bit unsigned integer value of a datum.
|
|
|
|
*/
|
|
|
|
|
2018-01-23 17:19:12 +01:00
|
|
|
#define DatumGetUInt8(X) ((uint8) (X))
|
2001-02-10 03:31:31 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* UInt8GetDatum
|
|
|
|
* Returns datum representation for an 8-bit unsigned integer.
|
|
|
|
*/
|
|
|
|
|
2018-01-23 17:19:12 +01:00
|
|
|
#define UInt8GetDatum(X) ((Datum) (X))
|
2001-02-10 03:31:31 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* DatumGetInt16
|
|
|
|
* Returns 16-bit integer value of a datum.
|
|
|
|
*/
|
|
|
|
|
2018-01-23 17:19:12 +01:00
|
|
|
#define DatumGetInt16(X) ((int16) (X))
|
2001-02-10 03:31:31 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Int16GetDatum
|
|
|
|
* Returns datum representation for a 16-bit integer.
|
|
|
|
*/
|
|
|
|
|
2018-01-23 17:19:12 +01:00
|
|
|
#define Int16GetDatum(X) ((Datum) (X))
|
2001-02-10 03:31:31 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* DatumGetUInt16
|
|
|
|
* Returns 16-bit unsigned integer value of a datum.
|
|
|
|
*/
|
|
|
|
|
2018-01-23 17:19:12 +01:00
|
|
|
#define DatumGetUInt16(X) ((uint16) (X))
|
2001-02-10 03:31:31 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* UInt16GetDatum
|
|
|
|
* Returns datum representation for a 16-bit unsigned integer.
|
|
|
|
*/
|
|
|
|
|
2018-01-23 17:19:12 +01:00
|
|
|
#define UInt16GetDatum(X) ((Datum) (X))
|
2001-02-10 03:31:31 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* DatumGetInt32
|
|
|
|
* Returns 32-bit integer value of a datum.
|
|
|
|
*/
|
|
|
|
|
2018-01-23 17:19:12 +01:00
|
|
|
#define DatumGetInt32(X) ((int32) (X))
|
2001-02-10 03:31:31 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Int32GetDatum
|
|
|
|
* Returns datum representation for a 32-bit integer.
|
|
|
|
*/
|
|
|
|
|
2018-01-23 17:19:12 +01:00
|
|
|
#define Int32GetDatum(X) ((Datum) (X))
|
2001-02-10 03:31:31 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* DatumGetUInt32
|
|
|
|
* Returns 32-bit unsigned integer value of a datum.
|
|
|
|
*/
|
|
|
|
|
2018-01-23 17:19:12 +01:00
|
|
|
#define DatumGetUInt32(X) ((uint32) (X))
|
2001-02-10 03:31:31 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* UInt32GetDatum
|
|
|
|
* Returns datum representation for a 32-bit unsigned integer.
|
|
|
|
*/
|
|
|
|
|
2018-01-23 17:19:12 +01:00
|
|
|
#define UInt32GetDatum(X) ((Datum) (X))
|
2001-02-10 03:31:31 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* DatumGetObjectId
|
|
|
|
* Returns object identifier value of a datum.
|
|
|
|
*/
|
|
|
|
|
2018-01-23 17:19:12 +01:00
|
|
|
#define DatumGetObjectId(X) ((Oid) (X))
|
2001-02-10 03:31:31 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* ObjectIdGetDatum
|
|
|
|
* Returns datum representation for an object identifier.
|
|
|
|
*/
|
|
|
|
|
2018-01-23 17:19:12 +01:00
|
|
|
#define ObjectIdGetDatum(X) ((Datum) (X))
|
2001-02-10 03:31:31 +01:00
|
|
|
|
2001-08-24 01:06:38 +02:00
|
|
|
/*
|
|
|
|
* DatumGetTransactionId
|
|
|
|
* Returns transaction identifier value of a datum.
|
|
|
|
*/
|
|
|
|
|
2018-01-23 17:19:12 +01:00
|
|
|
#define DatumGetTransactionId(X) ((TransactionId) (X))
|
2001-08-24 01:06:38 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* TransactionIdGetDatum
|
|
|
|
* Returns datum representation for a transaction identifier.
|
|
|
|
*/
|
|
|
|
|
2018-01-23 17:19:12 +01:00
|
|
|
#define TransactionIdGetDatum(X) ((Datum) (X))
|
2001-08-24 01:06:38 +02:00
|
|
|
|
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 16:04:59 +01:00
|
|
|
/*
|
|
|
|
* MultiXactIdGetDatum
|
2013-05-29 22:58:43 +02:00
|
|
|
* 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 16:04:59 +01:00
|
|
|
*/
|
|
|
|
|
2018-01-23 17:19:12 +01:00
|
|
|
#define MultiXactIdGetDatum(X) ((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 16:04:59 +01:00
|
|
|
|
2001-08-24 01:06:38 +02:00
|
|
|
/*
|
|
|
|
* DatumGetCommandId
|
|
|
|
* Returns command identifier value of a datum.
|
|
|
|
*/
|
|
|
|
|
2018-01-23 17:19:12 +01:00
|
|
|
#define DatumGetCommandId(X) ((CommandId) (X))
|
2001-08-24 01:06:38 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* CommandIdGetDatum
|
|
|
|
* Returns datum representation for a command identifier.
|
|
|
|
*/
|
|
|
|
|
2018-01-23 17:19:12 +01:00
|
|
|
#define CommandIdGetDatum(X) ((Datum) (X))
|
2001-08-24 01:06:38 +02:00
|
|
|
|
2001-02-10 03:31:31 +01:00
|
|
|
/*
|
|
|
|
* DatumGetPointer
|
|
|
|
* Returns pointer value of a datum.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define DatumGetPointer(X) ((Pointer) (X))
|
|
|
|
|
|
|
|
/*
|
|
|
|
* PointerGetDatum
|
|
|
|
* Returns datum representation for a pointer.
|
1999-03-25 04:49:34 +01:00
|
|
|
*/
|
1996-10-31 08:10:14 +01:00
|
|
|
|
2001-02-10 03:31:31 +01:00
|
|
|
#define PointerGetDatum(X) ((Datum) (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.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define DatumGetCString(X) ((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.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define CStringGetDatum(X) PointerGetDatum(X)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* DatumGetName
|
|
|
|
* Returns name value of a datum.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define DatumGetName(X) ((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.
|
|
|
|
*/
|
|
|
|
|
2016-09-13 23:17:48 +02:00
|
|
|
#define NameGetDatum(X) CStringGetDatum(NameStr(*(X)))
|
2001-02-10 03:31:31 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* DatumGetInt64
|
|
|
|
* Returns 64-bit integer value of a datum.
|
|
|
|
*
|
2008-04-21 02:26:47 +02:00
|
|
|
* Note: this macro hides whether int64 is pass by value or by reference.
|
2001-02-10 03:31:31 +01:00
|
|
|
*/
|
|
|
|
|
2008-04-21 02:26:47 +02:00
|
|
|
#ifdef USE_FLOAT8_BYVAL
|
2018-01-23 17:19:12 +01:00
|
|
|
#define DatumGetInt64(X) ((int64) (X))
|
2008-04-21 02:26:47 +02:00
|
|
|
#else
|
2001-02-10 03:31:31 +01:00
|
|
|
#define DatumGetInt64(X) (* ((int64 *) DatumGetPointer(X)))
|
2008-04-21 02:26:47 +02:00
|
|
|
#endif
|
2001-02-10 03:31:31 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Int64GetDatum
|
|
|
|
* Returns datum representation for a 64-bit integer.
|
|
|
|
*
|
2008-04-21 02:26:47 +02:00
|
|
|
* Note: if int64 is pass by reference, this function returns a reference
|
|
|
|
* to palloc'd space.
|
2001-02-10 03:31:31 +01:00
|
|
|
*/
|
|
|
|
|
2008-04-21 02:26:47 +02:00
|
|
|
#ifdef USE_FLOAT8_BYVAL
|
2018-01-23 17:19:12 +01:00
|
|
|
#define Int64GetDatum(X) ((Datum) (X))
|
2008-04-21 02:26:47 +02:00
|
|
|
#else
|
2001-02-10 03:31:31 +01:00
|
|
|
extern Datum Int64GetDatum(int64 X);
|
2008-04-21 02:26:47 +02:00
|
|
|
#endif
|
2001-02-10 03:31:31 +01:00
|
|
|
|
Widen query numbers-of-tuples-processed counters to uint64.
This patch widens SPI_processed, EState's es_processed field, PortalData's
portalPos field, FuncCallContext's call_cntr and max_calls fields,
ExecutorRun's count argument, PortalRunFetch's result, and the max number
of rows in a SPITupleTable to uint64, and deals with (I hope) all the
ensuing fallout. Some of these values were declared uint32 before, and
others "long".
I also removed PortalData's posOverflow field, since that logic seems
pretty useless given that portalPos is now always 64 bits.
The user-visible results are that command tags for SELECT etc will
correctly report tuple counts larger than 4G, as will plpgsql's GET
GET DIAGNOSTICS ... ROW_COUNT command. Queries processing more tuples
than that are still not exactly the norm, but they're becoming more
common.
Most values associated with FETCH/MOVE distances, such as PortalRun's count
argument and the count argument of most SPI functions that have one, remain
declared as "long". It's not clear whether it would be worth promoting
those to int64; but it would definitely be a large dollop of additional
API churn on top of this, and it would only help 32-bit platforms which
seem relatively less likely to see any benefit.
Andreas Scherbaum, reviewed by Christian Ullrich, additional hacking by me
2016-03-12 22:05:10 +01:00
|
|
|
/*
|
|
|
|
* DatumGetUInt64
|
|
|
|
* Returns 64-bit unsigned integer value of a datum.
|
|
|
|
*
|
|
|
|
* Note: this macro hides whether int64 is pass by value or by reference.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifdef USE_FLOAT8_BYVAL
|
2018-01-23 17:19:12 +01:00
|
|
|
#define DatumGetUInt64(X) ((uint64) (X))
|
Widen query numbers-of-tuples-processed counters to uint64.
This patch widens SPI_processed, EState's es_processed field, PortalData's
portalPos field, FuncCallContext's call_cntr and max_calls fields,
ExecutorRun's count argument, PortalRunFetch's result, and the max number
of rows in a SPITupleTable to uint64, and deals with (I hope) all the
ensuing fallout. Some of these values were declared uint32 before, and
others "long".
I also removed PortalData's posOverflow field, since that logic seems
pretty useless given that portalPos is now always 64 bits.
The user-visible results are that command tags for SELECT etc will
correctly report tuple counts larger than 4G, as will plpgsql's GET
GET DIAGNOSTICS ... ROW_COUNT command. Queries processing more tuples
than that are still not exactly the norm, but they're becoming more
common.
Most values associated with FETCH/MOVE distances, such as PortalRun's count
argument and the count argument of most SPI functions that have one, remain
declared as "long". It's not clear whether it would be worth promoting
those to int64; but it would definitely be a large dollop of additional
API churn on top of this, and it would only help 32-bit platforms which
seem relatively less likely to see any benefit.
Andreas Scherbaum, reviewed by Christian Ullrich, additional hacking by me
2016-03-12 22:05:10 +01:00
|
|
|
#else
|
|
|
|
#define DatumGetUInt64(X) (* ((uint64 *) DatumGetPointer(X)))
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* UInt64GetDatum
|
|
|
|
* Returns datum representation for a 64-bit unsigned integer.
|
|
|
|
*
|
|
|
|
* Note: if int64 is pass by reference, this function returns a reference
|
|
|
|
* to palloc'd space.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifdef USE_FLOAT8_BYVAL
|
2018-01-23 17:19:12 +01:00
|
|
|
#define UInt64GetDatum(X) ((Datum) (X))
|
Widen query numbers-of-tuples-processed counters to uint64.
This patch widens SPI_processed, EState's es_processed field, PortalData's
portalPos field, FuncCallContext's call_cntr and max_calls fields,
ExecutorRun's count argument, PortalRunFetch's result, and the max number
of rows in a SPITupleTable to uint64, and deals with (I hope) all the
ensuing fallout. Some of these values were declared uint32 before, and
others "long".
I also removed PortalData's posOverflow field, since that logic seems
pretty useless given that portalPos is now always 64 bits.
The user-visible results are that command tags for SELECT etc will
correctly report tuple counts larger than 4G, as will plpgsql's GET
GET DIAGNOSTICS ... ROW_COUNT command. Queries processing more tuples
than that are still not exactly the norm, but they're becoming more
common.
Most values associated with FETCH/MOVE distances, such as PortalRun's count
argument and the count argument of most SPI functions that have one, remain
declared as "long". It's not clear whether it would be worth promoting
those to int64; but it would definitely be a large dollop of additional
API churn on top of this, and it would only help 32-bit platforms which
seem relatively less likely to see any benefit.
Andreas Scherbaum, reviewed by Christian Ullrich, additional hacking by me
2016-03-12 22:05:10 +01:00
|
|
|
#else
|
|
|
|
#define UInt64GetDatum(X) Int64GetDatum((int64) (X))
|
|
|
|
#endif
|
|
|
|
|
2016-08-31 15:00:28 +02:00
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*/
|
|
|
|
|
2001-02-10 03:31:31 +01:00
|
|
|
/*
|
|
|
|
* DatumGetFloat4
|
|
|
|
* Returns 4-byte floating point value of a datum.
|
2008-04-21 02:26:47 +02:00
|
|
|
*
|
|
|
|
* Note: this macro hides whether float4 is pass by value or by reference.
|
2001-02-10 03:31:31 +01:00
|
|
|
*/
|
|
|
|
|
2008-04-21 02:26:47 +02:00
|
|
|
#ifdef USE_FLOAT4_BYVAL
|
2016-08-31 15:00:28 +02:00
|
|
|
static inline float4
|
|
|
|
DatumGetFloat4(Datum X)
|
|
|
|
{
|
|
|
|
union
|
|
|
|
{
|
|
|
|
int32 value;
|
|
|
|
float4 retval;
|
|
|
|
} myunion;
|
|
|
|
|
2017-05-31 17:27:21 +02:00
|
|
|
myunion.value = DatumGetInt32(X);
|
2016-08-31 15:00:28 +02:00
|
|
|
return myunion.retval;
|
|
|
|
}
|
2008-04-21 02:26:47 +02:00
|
|
|
#else
|
|
|
|
#define DatumGetFloat4(X) (* ((float4 *) DatumGetPointer(X)))
|
|
|
|
#endif
|
2001-02-10 03:31:31 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Float4GetDatum
|
|
|
|
* Returns datum representation for a 4-byte floating point number.
|
2008-04-21 02:26:47 +02:00
|
|
|
*
|
|
|
|
* Note: if float4 is pass by reference, this function returns a reference
|
|
|
|
* to palloc'd space.
|
2001-02-10 03:31:31 +01:00
|
|
|
*/
|
2016-08-31 15:00:28 +02:00
|
|
|
#ifdef USE_FLOAT4_BYVAL
|
|
|
|
static inline Datum
|
|
|
|
Float4GetDatum(float4 X)
|
|
|
|
{
|
|
|
|
union
|
|
|
|
{
|
|
|
|
float4 value;
|
|
|
|
int32 retval;
|
|
|
|
} myunion;
|
2001-02-10 03:31:31 +01:00
|
|
|
|
2016-08-31 15:00:28 +02:00
|
|
|
myunion.value = X;
|
2017-05-31 17:27:21 +02:00
|
|
|
return Int32GetDatum(myunion.retval);
|
2016-08-31 15:00:28 +02:00
|
|
|
}
|
|
|
|
#else
|
2001-02-10 03:31:31 +01:00
|
|
|
extern Datum Float4GetDatum(float4 X);
|
2016-08-31 15:00:28 +02:00
|
|
|
#endif
|
2001-02-10 03:31:31 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* DatumGetFloat8
|
|
|
|
* Returns 8-byte floating point value of a datum.
|
|
|
|
*
|
2008-04-21 02:26:47 +02:00
|
|
|
* Note: this macro hides whether float8 is pass by value or by reference.
|
2001-02-10 03:31:31 +01:00
|
|
|
*/
|
|
|
|
|
2008-04-21 02:26:47 +02:00
|
|
|
#ifdef USE_FLOAT8_BYVAL
|
2016-08-31 15:00:28 +02:00
|
|
|
static inline float8
|
|
|
|
DatumGetFloat8(Datum X)
|
|
|
|
{
|
|
|
|
union
|
|
|
|
{
|
|
|
|
int64 value;
|
|
|
|
float8 retval;
|
|
|
|
} myunion;
|
|
|
|
|
2017-05-31 17:27:21 +02:00
|
|
|
myunion.value = DatumGetInt64(X);
|
2016-08-31 15:00:28 +02:00
|
|
|
return myunion.retval;
|
|
|
|
}
|
2008-04-21 02:26:47 +02:00
|
|
|
#else
|
2001-02-10 03:31:31 +01:00
|
|
|
#define DatumGetFloat8(X) (* ((float8 *) DatumGetPointer(X)))
|
2008-04-21 02:26:47 +02:00
|
|
|
#endif
|
2001-02-10 03:31:31 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Float8GetDatum
|
|
|
|
* Returns datum representation for an 8-byte floating point number.
|
|
|
|
*
|
2008-04-21 02:26:47 +02:00
|
|
|
* Note: if float8 is pass by reference, this function returns a reference
|
|
|
|
* to palloc'd space.
|
2001-02-10 03:31:31 +01:00
|
|
|
*/
|
|
|
|
|
2016-08-31 15:00:28 +02:00
|
|
|
#ifdef USE_FLOAT8_BYVAL
|
|
|
|
static inline Datum
|
|
|
|
Float8GetDatum(float8 X)
|
|
|
|
{
|
|
|
|
union
|
|
|
|
{
|
|
|
|
float8 value;
|
|
|
|
int64 retval;
|
|
|
|
} myunion;
|
|
|
|
|
|
|
|
myunion.value = X;
|
2017-05-31 17:27:21 +02:00
|
|
|
return Int64GetDatum(myunion.retval);
|
2016-08-31 15:00:28 +02:00
|
|
|
}
|
|
|
|
#else
|
2001-02-10 03:31:31 +01:00
|
|
|
extern Datum Float8GetDatum(float8 X);
|
2016-08-31 15:00:28 +02:00
|
|
|
#endif
|
2001-02-10 03:31:31 +01:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Int64GetDatumFast
|
|
|
|
* Float8GetDatumFast
|
2008-04-21 02:26:47 +02:00
|
|
|
* Float4GetDatumFast
|
2001-02-10 03:31:31 +01:00
|
|
|
*
|
|
|
|
* These macros are intended to allow writing code that does not depend on
|
2008-04-21 02:26:47 +02:00
|
|
|
* whether int64, float8, float4 are pass-by-reference types, while not
|
2001-02-10 03:31:31 +01:00
|
|
|
* sacrificing performance when they are. The argument must be a variable
|
|
|
|
* that will exist and have the same value for as long as the Datum is needed.
|
|
|
|
* In the pass-by-ref case, the address of the variable is taken to use as
|
|
|
|
* the Datum. In the pass-by-val case, these will be the same as the non-Fast
|
|
|
|
* macros.
|
|
|
|
*/
|
|
|
|
|
2008-04-21 02:26:47 +02:00
|
|
|
#ifdef USE_FLOAT8_BYVAL
|
|
|
|
#define Int64GetDatumFast(X) Int64GetDatum(X)
|
|
|
|
#define Float8GetDatumFast(X) Float8GetDatum(X)
|
|
|
|
#else
|
2001-02-10 03:31:31 +01:00
|
|
|
#define Int64GetDatumFast(X) PointerGetDatum(&(X))
|
|
|
|
#define Float8GetDatumFast(X) PointerGetDatum(&(X))
|
2008-04-21 02:26:47 +02:00
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef USE_FLOAT4_BYVAL
|
|
|
|
#define Float4GetDatumFast(X) Float4GetDatum(X)
|
|
|
|
#else
|
|
|
|
#define Float4GetDatumFast(X) PointerGetDatum(&(X))
|
|
|
|
#endif
|
2001-02-10 03:31:31 +01:00
|
|
|
|
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 21:18:54 +02:00
|
|
|
#endif /* POSTGRES_H */
|