mirror of
https://github.com/postgres/postgres.git
synced 2025-05-08 07:21:33 +03:00
UBSan complains about this. Instead, cast to a suitable type requiring only 4-byte alignment. DatumGetAnyArrayP() already assumes one can cast between AnyArrayType and ArrayType, so this doesn't introduce a new assumption. Back-patch to 9.5, where AnyArrayType was introduced. Reviewed by Tom Lane. Discussion: https://postgr.es/m/20190629210334.GA1244217@rfd.leadboat.com
160 lines
6.9 KiB
C
160 lines
6.9 KiB
C
/*-------------------------------------------------------------------------
|
|
*
|
|
* expandeddatum.h
|
|
* Declarations for access to "expanded" value representations.
|
|
*
|
|
* Complex data types, particularly container types such as arrays and
|
|
* records, usually have on-disk representations that are compact but not
|
|
* especially convenient to modify. What's more, when we do modify them,
|
|
* having to recopy all the rest of the value can be extremely inefficient.
|
|
* Therefore, we provide a notion of an "expanded" representation that is used
|
|
* only in memory and is optimized more for computation than storage.
|
|
* The format appearing on disk is called the data type's "flattened"
|
|
* representation, since it is required to be a contiguous blob of bytes --
|
|
* but the type can have an expanded representation that is not. Data types
|
|
* must provide means to translate an expanded representation back to
|
|
* flattened form.
|
|
*
|
|
* An expanded object is meant to survive across multiple operations, but
|
|
* not to be enormously long-lived; for example it might be a local variable
|
|
* in a PL/pgSQL procedure. So its extra bulk compared to the on-disk format
|
|
* is a worthwhile trade-off.
|
|
*
|
|
* References to expanded objects are a type of TOAST pointer.
|
|
* Because of longstanding conventions in Postgres, this means that the
|
|
* flattened form of such an object must always be a varlena object.
|
|
* Fortunately that's no restriction in practice.
|
|
*
|
|
* There are actually two kinds of TOAST pointers for expanded objects:
|
|
* read-only and read-write pointers. Possession of one of the latter
|
|
* authorizes a function to modify the value in-place rather than copying it
|
|
* as would normally be required. Functions should always return a read-write
|
|
* pointer to any new expanded object they create. Functions that modify an
|
|
* argument value in-place must take care that they do not corrupt the old
|
|
* value if they fail partway through.
|
|
*
|
|
*
|
|
* Portions Copyright (c) 1996-2018, PostgreSQL Global Development Group
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
*
|
|
* src/include/utils/expandeddatum.h
|
|
*
|
|
*-------------------------------------------------------------------------
|
|
*/
|
|
#ifndef EXPANDEDDATUM_H
|
|
#define EXPANDEDDATUM_H
|
|
|
|
/* Size of an EXTERNAL datum that contains a pointer to an expanded object */
|
|
#define EXPANDED_POINTER_SIZE (VARHDRSZ_EXTERNAL + sizeof(varatt_expanded))
|
|
|
|
/*
|
|
* "Methods" that must be provided for any expanded object.
|
|
*
|
|
* get_flat_size: compute space needed for flattened representation (total,
|
|
* including header).
|
|
*
|
|
* flatten_into: construct flattened representation in the caller-allocated
|
|
* space at *result, of size allocated_size (which will always be the result
|
|
* of a preceding get_flat_size call; it's passed for cross-checking).
|
|
*
|
|
* The flattened representation must be a valid in-line, non-compressed,
|
|
* 4-byte-header varlena object.
|
|
*
|
|
* Note: construction of a heap tuple from an expanded datum calls
|
|
* get_flat_size twice, so it's worthwhile to make sure that that doesn't
|
|
* incur too much overhead.
|
|
*/
|
|
typedef Size (*EOM_get_flat_size_method) (ExpandedObjectHeader *eohptr);
|
|
typedef void (*EOM_flatten_into_method) (ExpandedObjectHeader *eohptr,
|
|
void *result, Size allocated_size);
|
|
|
|
/* Struct of function pointers for an expanded object's methods */
|
|
typedef struct ExpandedObjectMethods
|
|
{
|
|
EOM_get_flat_size_method get_flat_size;
|
|
EOM_flatten_into_method flatten_into;
|
|
} ExpandedObjectMethods;
|
|
|
|
/*
|
|
* Every expanded object must contain this header; typically the header
|
|
* is embedded in some larger struct that adds type-specific fields.
|
|
*
|
|
* It is presumed that the header object and all subsidiary data are stored
|
|
* in eoh_context, so that the object can be freed by deleting that context,
|
|
* or its storage lifespan can be altered by reparenting the context.
|
|
* (In principle the object could own additional resources, such as malloc'd
|
|
* storage, and use a memory context reset callback to free them upon reset or
|
|
* deletion of eoh_context.)
|
|
*
|
|
* We set up two TOAST pointers within the standard header, one read-write
|
|
* and one read-only. This allows functions to return either kind of pointer
|
|
* without making an additional allocation, and in particular without worrying
|
|
* whether a separately palloc'd object would have sufficient lifespan.
|
|
* But note that these pointers are just a convenience; a pointer object
|
|
* appearing somewhere else would still be legal.
|
|
*
|
|
* The typedef declaration for this appears in postgres.h.
|
|
*/
|
|
struct ExpandedObjectHeader
|
|
{
|
|
/* Phony varlena header */
|
|
int32 vl_len_; /* always EOH_HEADER_MAGIC, see below */
|
|
|
|
/* Pointer to methods required for object type */
|
|
const ExpandedObjectMethods *eoh_methods;
|
|
|
|
/* Memory context containing this header and subsidiary data */
|
|
MemoryContext eoh_context;
|
|
|
|
/* Standard R/W TOAST pointer for this object is kept here */
|
|
char eoh_rw_ptr[EXPANDED_POINTER_SIZE];
|
|
|
|
/* Standard R/O TOAST pointer for this object is kept here */
|
|
char eoh_ro_ptr[EXPANDED_POINTER_SIZE];
|
|
};
|
|
|
|
/*
|
|
* Particularly for read-only functions, it is handy to be able to work with
|
|
* either regular "flat" varlena inputs or expanded inputs of the same data
|
|
* type. To allow determining which case an argument-fetching function has
|
|
* returned, the first int32 of an ExpandedObjectHeader always contains -1
|
|
* (EOH_HEADER_MAGIC to the code). This works since no 4-byte-header varlena
|
|
* could have that as its first 4 bytes. Caution: we could not reliably tell
|
|
* the difference between an ExpandedObjectHeader and a short-header object
|
|
* with this trick. However, it works fine if the argument fetching code
|
|
* always returns either a 4-byte-header flat object or an expanded object.
|
|
*/
|
|
#define EOH_HEADER_MAGIC (-1)
|
|
#define VARATT_IS_EXPANDED_HEADER(PTR) \
|
|
(((varattrib_4b *) (PTR))->va_4byte.va_header == EOH_HEADER_MAGIC)
|
|
|
|
/*
|
|
* Generic support functions for expanded objects.
|
|
* (More of these might be worth inlining later.)
|
|
*/
|
|
|
|
#define EOHPGetRWDatum(eohptr) PointerGetDatum((eohptr)->eoh_rw_ptr)
|
|
#define EOHPGetRODatum(eohptr) PointerGetDatum((eohptr)->eoh_ro_ptr)
|
|
|
|
/* Does the Datum represent a writable expanded object? */
|
|
#define DatumIsReadWriteExpandedObject(d, isnull, typlen) \
|
|
(((isnull) || (typlen) != -1) ? false : \
|
|
VARATT_IS_EXTERNAL_EXPANDED_RW(DatumGetPointer(d)))
|
|
|
|
#define MakeExpandedObjectReadOnly(d, isnull, typlen) \
|
|
(((isnull) || (typlen) != -1) ? (d) : \
|
|
MakeExpandedObjectReadOnlyInternal(d))
|
|
|
|
extern ExpandedObjectHeader *DatumGetEOHP(Datum d);
|
|
extern void EOH_init_header(ExpandedObjectHeader *eohptr,
|
|
const ExpandedObjectMethods *methods,
|
|
MemoryContext obj_context);
|
|
extern Size EOH_get_flat_size(ExpandedObjectHeader *eohptr);
|
|
extern void EOH_flatten_into(ExpandedObjectHeader *eohptr,
|
|
void *result, Size allocated_size);
|
|
extern Datum MakeExpandedObjectReadOnlyInternal(Datum d);
|
|
extern Datum TransferExpandedObject(Datum d, MemoryContext new_parent);
|
|
extern void DeleteExpandedObject(Datum d);
|
|
|
|
#endif /* EXPANDEDDATUM_H */
|