Skip to content

Commit 2616a5d

Browse files
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)