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

Skip to content

Commit 0b44914

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 17b04a1 commit 0b44914

File tree

670 files changed

+3546
-3546
lines changed

Some content is hidden

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

670 files changed

+3546
-3546
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
@@ -563,7 +563,7 @@ g_cube_picksplit(PG_FUNCTION_ARGS)
563563
rt_cube_size(datum_r, &size_r);
564564

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

‎contrib/dblink/dblink.c

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

25482548
/*
2549-
* For non-superusers, insist that the connstr specify a password. This
2549+
* For non-superusers, insist that the connstr specify a password. This
25502550
* prevents a password from being picked up from .pgpass, a service file,
25512551
* the environment, etc. We don't want the postgres user's passwords
25522552
* 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
@@ -747,7 +747,7 @@ estimate_size(PlannerInfo *root, RelOptInfo *baserel,
747747
* planner's idea of the relation width; which is bogus if not all
748748
* columns are being read, not to mention that the text representation
749749
* of a row probably isn't the same size as its internal
750-
* representation. Possibly we could do something better, but the
750+
* representation. Possibly we could do something better, but the
751751
* real answer to anyone who complains is "ANALYZE" ...
752752
*/
753753
int tuple_width;
@@ -812,7 +812,7 @@ estimate_costs(PlannerInfo *root, RelOptInfo *baserel,
812812
* which must have at least targrows entries.
813813
* The actual number of rows selected is returned as the function result.
814814
* We also count the total number of rows in the file and return it into
815-
* *totalrows. Note that *totaldeadrows is always set to 0.
815+
* *totalrows. Note that *totaldeadrows is always set to 0.
816816
*
817817
* Note that the returned list of rows is not always in order by physical
818818
* 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
@@ -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)