mirror of
https://git.postgresql.org/git/postgresql.git
synced 2026-02-11 20:57:30 +08:00
c7b8998ebb
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
60 lines
1.9 KiB
C
60 lines
1.9 KiB
C
/*-------------------------------------------------------------------------
|
|
*
|
|
* datum.h
|
|
* POSTGRES Datum (abstract data type) manipulation routines.
|
|
*
|
|
* 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.)
|
|
*
|
|
* Portions Copyright (c) 1996-2017, PostgreSQL Global Development Group
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
*
|
|
* src/include/utils/datum.h
|
|
*
|
|
*-------------------------------------------------------------------------
|
|
*/
|
|
#ifndef DATUM_H
|
|
#define DATUM_H
|
|
|
|
/*
|
|
* datumGetSize - find the "real" length of a datum
|
|
*/
|
|
extern Size datumGetSize(Datum value, bool typByVal, int typLen);
|
|
|
|
/*
|
|
* datumCopy - make a copy of a non-NULL datum.
|
|
*
|
|
* If the datatype is pass-by-reference, memory is obtained with palloc().
|
|
*/
|
|
extern Datum datumCopy(Datum value, bool typByVal, int typLen);
|
|
|
|
/*
|
|
* datumTransfer - transfer a non-NULL datum into the current memory context.
|
|
*
|
|
* Differs from datumCopy() in its handling of read-write expanded objects.
|
|
*/
|
|
extern Datum datumTransfer(Datum value, bool typByVal, int typLen);
|
|
|
|
/*
|
|
* datumIsEqual
|
|
* return true if two datums of the same type are equal, false otherwise.
|
|
*
|
|
* XXX : See comments in the code for restrictions!
|
|
*/
|
|
extern bool datumIsEqual(Datum value1, Datum value2,
|
|
bool typByVal, int typLen);
|
|
|
|
/*
|
|
* Serialize and restore datums so that we can transfer them to parallel
|
|
* workers.
|
|
*/
|
|
extern Size datumEstimateSpace(Datum value, bool isnull, bool typByVal,
|
|
int typLen);
|
|
extern void datumSerialize(Datum value, bool isnull, bool typByVal,
|
|
int typLen, char **start_address);
|
|
extern Datum datumRestore(char **start_address, bool *isnull);
|
|
|
|
#endif /* DATUM_H */
|