1996-08-28 03:59:28 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* datum.h
|
2000-07-12 04:37:39 +02:00
|
|
|
* POSTGRES Datum (abstract data type) manipulation routines.
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
2000-07-12 04:37:39 +02:00
|
|
|
* These routines are driven by the 'typbyval' and 'typlen' information,
|
|
|
|
* which must previously have been obtained by the caller for the datatype
|
|
|
|
* of the Datum. (We do it this way because in most situations the caller
|
|
|
|
* can look up the info just once and use it for many per-datum operations.)
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
2020-01-01 18:21:45 +01:00
|
|
|
* Portions Copyright (c) 1996-2020, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/include/utils/datum.h
|
1996-08-28 03:59:28 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
1997-09-07 07:04:48 +02:00
|
|
|
#ifndef DATUM_H
|
|
|
|
#define DATUM_H
|
1996-08-28 03:59:28 +02:00
|
|
|
|
2000-07-12 04:37:39 +02:00
|
|
|
/*
|
|
|
|
* datumGetSize - find the "real" length of a datum
|
1996-08-28 03:59:28 +02:00
|
|
|
*/
|
2000-07-12 04:37:39 +02:00
|
|
|
extern Size datumGetSize(Datum value, bool typByVal, int typLen);
|
1996-08-28 03:59:28 +02:00
|
|
|
|
2000-07-12 04:37:39 +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
|
|
|
* datumCopy - make a copy of a non-NULL datum.
|
2000-07-12 04:37:39 +02:00
|
|
|
*
|
|
|
|
* If the datatype is pass-by-reference, memory is obtained with palloc().
|
1996-08-28 03:59:28 +02:00
|
|
|
*/
|
2000-07-12 04:37:39 +02:00
|
|
|
extern Datum datumCopy(Datum value, bool typByVal, int typLen);
|
1996-08-28 03:59:28 +02:00
|
|
|
|
2000-07-12 04:37:39 +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
|
|
|
* datumTransfer - transfer a non-NULL datum into the current memory context.
|
2000-07-12 04:37:39 +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
|
|
|
* Differs from datumCopy() in its handling of read-write expanded objects.
|
1996-08-28 03:59:28 +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
|
|
|
extern Datum datumTransfer(Datum value, bool typByVal, int typLen);
|
1996-08-28 03:59:28 +02:00
|
|
|
|
2000-07-12 04:37:39 +02:00
|
|
|
/*
|
1996-08-28 03:59:28 +02:00
|
|
|
* datumIsEqual
|
2000-07-12 04:37:39 +02:00
|
|
|
* return true if two datums of the same type are equal, false otherwise.
|
|
|
|
*
|
1996-08-28 03:59:28 +02:00
|
|
|
* XXX : See comments in the code for restrictions!
|
|
|
|
*/
|
2000-07-12 04:37:39 +02:00
|
|
|
extern bool datumIsEqual(Datum value1, Datum value2,
|
2019-05-22 19:04:48 +02:00
|
|
|
bool typByVal, int typLen);
|
2001-10-28 07:26:15 +01:00
|
|
|
|
2019-03-18 17:01:40 +01:00
|
|
|
/*
|
|
|
|
* datum_image_eq
|
|
|
|
*
|
|
|
|
* Compares two datums for identical contents, based on byte images. Return
|
|
|
|
* true if the two datums are equal, false otherwise.
|
|
|
|
*/
|
|
|
|
extern bool datum_image_eq(Datum value1, Datum value2,
|
2019-05-22 19:04:48 +02:00
|
|
|
bool typByVal, int typLen);
|
2019-03-18 17:01:40 +01:00
|
|
|
|
2015-09-29 03:55:57 +02:00
|
|
|
/*
|
|
|
|
* Serialize and restore datums so that we can transfer them to parallel
|
|
|
|
* workers.
|
|
|
|
*/
|
|
|
|
extern Size datumEstimateSpace(Datum value, bool isnull, bool typByVal,
|
2019-05-22 19:04:48 +02:00
|
|
|
int typLen);
|
2015-09-29 03:55:57 +02:00
|
|
|
extern void datumSerialize(Datum value, bool isnull, bool typByVal,
|
2019-05-22 19:04:48 +02:00
|
|
|
int typLen, char **start_address);
|
2015-09-29 03:55:57 +02:00
|
|
|
extern Datum datumRestore(char **start_address, bool *isnull);
|
|
|
|
|
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 /* DATUM_H */
|