diff options
Diffstat (limited to 'src/backend/regex/regprefix.c')
| -rw-r--r-- | src/backend/regex/regprefix.c | 18 |
1 files changed, 9 insertions, 9 deletions
diff --git a/src/backend/regex/regprefix.c b/src/backend/regex/regprefix.c index d1b7974cafe..abda80c094e 100644 --- a/src/backend/regex/regprefix.c +++ b/src/backend/regex/regprefix.c @@ -20,7 +20,7 @@ * forward declarations */ static int findprefix(struct cnfa * cnfa, struct colormap * cm, - chr *string, size_t *slength); + chr *string, size_t *slength); /* @@ -38,7 +38,7 @@ static int findprefix(struct cnfa * cnfa, struct colormap * cm, * * This function does not analyze all complex cases (such as lookahead * constraints) exactly. Therefore it is possible that some strings matching - * the reported prefix or exact-match string do not satisfy the regex. But + * the reported prefix or exact-match string do not satisfy the regex. But * it should never be the case that a string satisfying the regex does not * match the reported prefix or exact-match string. */ @@ -79,8 +79,8 @@ pg_regprefix(regex_t *re, /* * Since a correct NFA should never contain any exit-free loops, it should - * not be possible for our traversal to return to a previously visited - * NFA state. Hence we need at most nstates chrs in the output string. + * not be possible for our traversal to return to a previously visited NFA + * state. Hence we need at most nstates chrs in the output string. */ *string = (chr *) MALLOC(cnfa->nstates * sizeof(chr)); if (*string == NULL) @@ -122,8 +122,8 @@ findprefix(struct cnfa * cnfa, /* * The "pre" state must have only BOS/BOL outarcs, else pattern isn't - * anchored left. If we have both BOS and BOL, they must go to the - * same next state. + * anchored left. If we have both BOS and BOL, they must go to the same + * next state. */ st = cnfa->pre; nextst = -1; @@ -150,7 +150,7 @@ findprefix(struct cnfa * cnfa, * We could find a state with multiple out-arcs that are all labeled with * the same singleton color; this comes from patterns like "^ab(cde|cxy)". * In that case we add the chr "c" to the output string but then exit the - * loop with nextst == -1. This leaves a little bit on the table: if the + * loop with nextst == -1. This leaves a little bit on the table: if the * pattern is like "^ab(cde|cdy)", we won't notice that "d" could be added * to the prefix. But chasing multiple parallel state chains doesn't seem * worth the trouble. @@ -201,14 +201,14 @@ findprefix(struct cnfa * cnfa, /* * Identify the color's sole member chr and add it to the prefix - * string. In general the colormap data structure doesn't provide a + * string. In general the colormap data structure doesn't provide a * way to find color member chrs, except by trying GETCOLOR() on each * possible chr value, which won't do at all. However, for the cases * we care about it should be sufficient to test the "firstchr" value, * that is the first chr ever added to the color. There are cases * where this might no longer be a member of the color (so we do need * to test), but none of them are likely to arise for a character that - * is a member of a common prefix. If we do hit such a corner case, + * is a member of a common prefix. If we do hit such a corner case, * we just fall out without adding anything to the prefix string. */ c = cm->cd[thiscolor].firstchr; |