Skip to content

Commit 2616a5d

Browse files
bmomjianbmomjian
committed
Remove tabs after spaces in C comments
This was not changed in HEAD, but will be done later as part of a pgindent run. Future pgindent runs will also do this. Report by Tom Lane Backpatch through all supported branches, but not HEAD
1 parent e0070a6 commit 2616a5d

File tree

623 files changed

+3206
-3206
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

623 files changed

+3206
-3206
lines changed

‎contrib/btree_gist/btree_interval.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -93,7 +93,7 @@ gbt_intv_dist(const void *a, const void *b)
9393

9494
/*
9595
* INTERVALSIZE should be the actual size-on-disk of an Interval, as shown
96-
* in pg_type. This might be less than sizeof(Interval) if the compiler
96+
* in pg_type. This might be less than sizeof(Interval) if the compiler
9797
* insists on adding alignment padding at the end of the struct.
9898
*/
9999
#define INTERVALSIZE 16

‎contrib/cube/cube.c

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -564,7 +564,7 @@ g_cube_picksplit(PG_FUNCTION_ARGS)
564564
rt_cube_size(datum_r, &size_r);
565565

566566
/*
567-
* Now split up the regions between the two seeds. An important property
567+
* Now split up the regions between the two seeds. An important property
568568
* of this split algorithm is that the split vector v has the indices of
569569
* items to be split in order in its left and right vectors. We exploit
570570
* this property by doing a merge in the code that actually splits the
@@ -580,7 +580,7 @@ g_cube_picksplit(PG_FUNCTION_ARGS)
580580
{
581581
/*
582582
* If we've already decided where to place this item, just put it on
583-
* the right list. Otherwise, we need to figure out which page needs
583+
* the right list. Otherwise, we need to figure out which page needs
584584
* the least enlargement in order to store the item.
585585
*/
586586

‎contrib/dblink/dblink.c

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1987,7 +1987,7 @@ get_tuple_of_interest(Relation rel, int *pkattnums, int pknumatts, char **src_pk
19871987
* Build sql statement to look up tuple of interest, ie, the one matching
19881988
* src_pkattvals. We used to use "SELECT *" here, but it's simpler to
19891989
* generate a result tuple that matches the table's physical structure,
1990-
* with NULLs for any dropped columns. Otherwise we have to deal with two
1990+
* with NULLs for any dropped columns. Otherwise we have to deal with two
19911991
* different tupdescs and everything's very confusing.
19921992
*/
19931993
appendStringInfoString(&buf, "SELECT ");
@@ -2213,7 +2213,7 @@ dblink_security_check(PGconn *conn, remoteConn *rconn)
22132213
}
22142214

22152215
/*
2216-
* For non-superusers, insist that the connstr specify a password. This
2216+
* For non-superusers, insist that the connstr specify a password. This
22172217
* prevents a password from being picked up from .pgpass, a service file,
22182218
* the environment, etc. We don't want the postgres user's passwords
22192219
* to be accessible to non-superusers.

‎contrib/earthdistance/earthdistance.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -91,7 +91,7 @@ geo_distance_internal(Point *pt1, Point *pt2)
9191
* distance between the points in miles on earth's surface
9292
*
9393
* If float8 is passed-by-value, the oldstyle version-0 calling convention
94-
* is unportable, so we use version-1. However, if it's passed-by-reference,
94+
* is unportable, so we use version-1. However, if it's passed-by-reference,
9595
* continue to use oldstyle. This is just because we'd like earthdistance
9696
* to serve as a canary for any unintentional breakage of version-0 functions
9797
* with float8 results.

‎contrib/file_fdw/file_fdw.c

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -518,7 +518,7 @@ estimate_costs(PlannerInfo *root, RelOptInfo *baserel,
518518

519519
/*
520520
* Now estimate the number of rows returned by the scan after applying the
521-
* baserestrictinfo quals. This is pretty bogus too, since the planner
521+
* baserestrictinfo quals. This is pretty bogus too, since the planner
522522
* will have no stats about the relation, but it's better than nothing.
523523
*/
524524
nrows = ntuples *
@@ -534,7 +534,7 @@ estimate_costs(PlannerInfo *root, RelOptInfo *baserel,
534534
baserel->rows = nrows;
535535

536536
/*
537-
* Now estimate costs. We estimate costs almost the same way as
537+
* Now estimate costs. We estimate costs almost the same way as
538538
* cost_seqscan(), thus assuming that I/O costs are equivalent to a
539539
* regular table file of the same size. However, we take per-tuple CPU
540540
* costs as 10x of a seqscan, to account for the cost of parsing records.

‎contrib/fuzzystrmatch/levenshtein.c

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -50,7 +50,7 @@ static int levenshtein_internal(text *s, text *t,
5050
* array.
5151
*
5252
* If max_d >= 0, we only need to provide an accurate answer when that answer
53-
* is less than or equal to the bound. From any cell in the matrix, there is
53+
* is less than or equal to the bound. From any cell in the matrix, there is
5454
* theoretical "minimum residual distance" from that cell to the last column
5555
* of the final row. This minimum residual distance is zero when the
5656
* untransformed portions of the strings are of equal length (because we might
@@ -141,7 +141,7 @@ levenshtein_internal(text *s, text *t,
141141
stop_column = m + 1;
142142

143143
/*
144-
* If max_d >= 0, determine whether the bound is impossibly tight. If so,
144+
* If max_d >= 0, determine whether the bound is impossibly tight. If so,
145145
* return max_d + 1 immediately. Otherwise, determine whether it's tight
146146
* enough to limit the computation we must perform. If so, figure out
147147
* initial stop column.
@@ -168,7 +168,7 @@ levenshtein_internal(text *s, text *t,
168168
* need to fill in. If the string is growing, the theoretical
169169
* minimum distance already incorporates the cost of deleting the
170170
* number of characters necessary to make the two strings equal in
171-
* length. Each additional deletion forces another insertion, so
171+
* length. Each additional deletion forces another insertion, so
172172
* the best-case total cost increases by ins_c + del_c. If the
173173
* string is shrinking, the minimum theoretical cost assumes no
174174
* excess deletions; that is, we're starting no futher right than
@@ -246,7 +246,7 @@ levenshtein_internal(text *s, text *t,
246246
/*
247247
* The main loop fills in curr, but curr[0] needs a special case: to
248248
* transform the first 0 characters of s into the first j characters
249-
* of t, we must perform j insertions. However, if start_column > 0,
249+
* of t, we must perform j insertions. However, if start_column > 0,
250250
* this special case does not apply.
251251
*/
252252
if (start_column == 0)

‎contrib/hstore/hstore.h

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,7 @@
1212
* HEntry: there is one of these for each key _and_ value in an hstore
1313
*
1414
* the position offset points to the _end_ so that we can get the length
15-
* by subtraction from the previous entry. the ISFIRST flag lets us tell
15+
* by subtraction from the previous entry. the ISFIRST flag lets us tell
1616
* whether there is a previous entry.
1717
*/
1818
typedef struct

‎contrib/hstore/hstore_gin.c

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -13,7 +13,7 @@
1313
/*
1414
* When using a GIN index for hstore, we choose to index both keys and values.
1515
* The storage format is "text" values, with K, V, or N prepended to the string
16-
* to indicate key, value, or null values. (As of 9.1 it might be better to
16+
* to indicate key, value, or null values. (As of 9.1 it might be better to
1717
* store null values as nulls, but we'll keep it this way for on-disk
1818
* compatibility.)
1919
*/
@@ -168,7 +168,7 @@ gin_consistent_hstore(PG_FUNCTION_ARGS)
168168
{
169169
/*
170170
* Index doesn't have information about correspondence of keys and
171-
* values, so we need recheck. However, if not all the keys are
171+
* values, so we need recheck. However, if not all the keys are
172172
* present, we can fail at once.
173173
*/
174174
*recheck = true;

‎contrib/intarray/_int_bool.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -355,7 +355,7 @@ gin_bool_consistent(QUERYTYPE *query, bool *check)
355355
return FALSE;
356356

357357
/*
358-
* Set up data for checkcondition_gin. This must agree with the query
358+
* Set up data for checkcondition_gin. This must agree with the query
359359
* extraction code in ginint4_queryextract.
360360
*/
361361
gcv.first = items;

‎contrib/intarray/_int_gist.c

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -482,7 +482,7 @@ g_int_picksplit(PG_FUNCTION_ARGS)
482482
qsort((void *) costvector, maxoff, sizeof(SPLITCOST), comparecost);
483483

484484
/*
485-
* Now split up the regions between the two seeds. An important property
485+
* Now split up the regions between the two seeds. An important property
486486
* of this split algorithm is that the split vector v has the indices of
487487
* items to be split in order in its left and right vectors. We exploit
488488
* this property by doing a merge in the code that actually splits the
@@ -500,7 +500,7 @@ g_int_picksplit(PG_FUNCTION_ARGS)
500500

501501
/*
502502
* If we've already decided where to place this item, just put it on
503-
* the right list. Otherwise, we need to figure out which page needs
503+
* the right list. Otherwise, we need to figure out which page needs
504504
* the least enlargement in order to store the item.
505505
*/
506506

0 commit comments

Comments
 (0)
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy