Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit 04e15c6

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 41fdcf7 commit 04e15c6

File tree

699 files changed

+3823
-3823
lines changed

Some content is hidden

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

699 files changed

+3823
-3823
lines changed

‎contrib/btree_gist/btree_interval.c

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

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

‎contrib/cube/cube.c

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

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

‎contrib/dblink/dblink.c

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

26252625
/*
2626-
* For non-superusers, insist that the connstr specify a password. This
2626+
* For non-superusers, insist that the connstr specify a password. This
26272627
* prevents a password from being picked up from .pgpass, a service file,
26282628
* the environment, etc. We don't want the postgres user's passwords
26292629
* 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: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -478,7 +478,7 @@ fileGetForeignPaths(PlannerInfo *root,
478478
&startup_cost, &total_cost);
479479

480480
/*
481-
* Create a ForeignPath node and add it as only possible path. We use the
481+
* Create a ForeignPath node and add it as only possible path. We use the
482482
* fdw_private list of the path to carry the convert_selectively option;
483483
* it will be propagated into the fdw_private list of the Plan node.
484484
*/
@@ -891,7 +891,7 @@ estimate_size(PlannerInfo *root, RelOptInfo *baserel,
891891
* planner's idea of the relation width; which is bogus if not all
892892
* columns are being read, not to mention that the text representation
893893
* of a row probably isn't the same size as its internal
894-
* representation. Possibly we could do something better, but the
894+
* representation. Possibly we could do something better, but the
895895
* real answer to anyone who complains is "ANALYZE" ...
896896
*/
897897
int tuple_width;
@@ -956,7 +956,7 @@ estimate_costs(PlannerInfo *root, RelOptInfo *baserel,
956956
* which must have at least targrows entries.
957957
* The actual number of rows selected is returned as the function result.
958958
* We also count the total number of rows in the file and return it into
959-
* *totalrows. Note that *totaldeadrows is always set to 0.
959+
* *totalrows. Note that *totaldeadrows is always set to 0.
960960
*
961961
* Note that the returned list of rows is not always in order by physical
962962
* position in the file. Therefore, correlation estimates derived later

‎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 further 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
@@ -353,7 +353,7 @@ gin_bool_consistent(QUERYTYPE *query, bool *check)
353353
return FALSE;
354354

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

‎contrib/intarray/_int_gist.c

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

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

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

0 commit comments

Comments
 (0)