database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-11-18 02:02:55 +03:00
Code Activity

Pre-beta mechanical code beautification.

Browse Source 
Run pgindent, pgperltidy, and reformat-dat-files.

This set of diffs is a bit larger than typical.  We've updated to
pg_bsd_indent 2.1.2, which properly indents variable declarations that
have multi-line initialization expressions (the continuation lines are
now indented one tab stop).  We've also updated to perltidy version
20230309 and changed some of its settings, which reduces its desire to
add whitespace to lines to make assignments etc. line up.  Going
forward, that should make for fewer random-seeming changes to existing
code.

Discussion: https://postgr.es/m/20230428092545.qfb3y5wcu4cm75ur@alvherre.pgsql
This commit is contained in:
Tom Lane
2023-05-19 17:24:48 -04:00
parent df6b19fbbc
commit 0245f8db36
402 changed files with 4756 additions and 4427 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
src/backend/utils/cache/relcache.c vendored
View File

@@ -3084,10 +3084,10 @@ static void
AssertPendingSyncConsistency(Relation relation)
{
bool relcache_verdict =
RelationIsPermanent(relation) &&
((relation->rd_createSubid != InvalidSubTransactionId &&
RELKIND_HAS_STORAGE(relation->rd_rel->relkind)) ||
relation->rd_firstRelfilelocatorSubid != InvalidSubTransactionId);
RelationIsPermanent(relation) &&
((relation->rd_createSubid != InvalidSubTransactionId &&
RELKIND_HAS_STORAGE(relation->rd_rel->relkind)) ||
relation->rd_firstRelfilelocatorSubid != InvalidSubTransactionId);
Assert(relcache_verdict == RelFileLocatorSkippingWAL(relation->rd_locator));
@@ -3765,12 +3765,12 @@ RelationSetNewRelfilenumber(Relation relation, char persistence)
*/
if (IsBinaryUpgrade)
{
SMgrRelation srel;
SMgrRelation srel;
/*
* During a binary upgrade, we use this code path to ensure that
* pg_largeobject and its index have the same relfilenumbers as in
* the old cluster. This is necessary because pg_upgrade treats
* pg_largeobject and its index have the same relfilenumbers as in the
* old cluster. This is necessary because pg_upgrade treats
* pg_largeobject like a user table, not a system table. It is however
* possible that a table or index may need to end up with the same
* relfilenumber in the new cluster as what it had in the old cluster.
@@ -5171,8 +5171,8 @@ RelationGetIndexAttrBitmap(Relation relation, IndexAttrBitmapKind attrKind)
Bitmapset *uindexattrs; /* columns in unique indexes */
Bitmapset *pkindexattrs; /* columns in the primary index */
Bitmapset *idindexattrs; /* columns in the replica identity */
Bitmapset *hotblockingattrs; /* columns with HOT blocking indexes */
Bitmapset *summarizedattrs; /* columns with summarizing indexes */
Bitmapset *hotblockingattrs; /* columns with HOT blocking indexes */
Bitmapset *summarizedattrs; /* columns with summarizing indexes */
List *indexoidlist;
List *newindexoidlist;
Oid relpkindex;
@@ -5314,8 +5314,8 @@ restart:
* when the column value changes, thus require a separate
* attribute bitmapset.
*
* Obviously, non-key columns couldn't be referenced by
* foreign key or identity key. Hence we do not include them into
* Obviously, non-key columns couldn't be referenced by foreign
* key or identity key. Hence we do not include them into
* uindexattrs, pkindexattrs and idindexattrs bitmaps.
*/
if (attrnum != 0)