Code cleanup for build_regexp_split_result
Started by Li Japinalmost 6 years ago2 messages
Hi hackers,
I find the build_regexp_split_result() has redundant codes, we can move it to before the condition check, can we?
Best regards.
Japin Li
Attachments:
0001-Code-cleanup-for-build_regexp_split_result.patchapplication/octet-stream; name=0001-Code-cleanup-for-build_regexp_split_result.patchDownload
From 16ba83673db3667a0862b255ca3edcfdabd41237 Mon Sep 17 00:00:00 2001
From: japinli <japinli@hotmail.com>
Date: Thu, 16 Jan 2020 23:02:21 +0800
Subject: [PATCH] Code cleanup for build_regexp_split_result
---
src/backend/utils/adt/regexp.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/src/backend/utils/adt/regexp.c b/src/backend/utils/adt/regexp.c
index 2094d50d81..c5d5a5f9db 100644
--- a/src/backend/utils/adt/regexp.c
+++ b/src/backend/utils/adt/regexp.c
@@ -1467,14 +1467,15 @@ build_regexp_split_result(regexp_matches_ctx *splitctx)
if (startpos < 0)
elog(ERROR, "invalid match ending position");
+ endpos = splitctx->match_locs[splitctx->next_match * 2];
+ if (endpos < startpos)
+ elog(ERROR, "invalid match starting position");
+
if (buf)
{
int bufsiz PG_USED_FOR_ASSERTS_ONLY = splitctx->conv_bufsiz;
int len;
- endpos = splitctx->match_locs[splitctx->next_match * 2];
- if (endpos < startpos)
- elog(ERROR, "invalid match starting position");
len = pg_wchar2mb_with_len(splitctx->wide_str + startpos,
buf,
endpos - startpos);
@@ -1483,9 +1484,6 @@ build_regexp_split_result(regexp_matches_ctx *splitctx)
}
else
{
- endpos = splitctx->match_locs[splitctx->next_match * 2];
- if (endpos < startpos)
- elog(ERROR, "invalid match starting position");
return DirectFunctionCall3(text_substr,
PointerGetDatum(splitctx->orig_str),
Int32GetDatum(startpos + 1),
--
2.17.1
Re: Code cleanup for build_regexp_split_result
Li Japin <japinli@hotmail.com> writes:
I find the build_regexp_split_result() has redundant codes, we can move it to before the condition check, can we?
Hm, yeah, that looks a bit strange. It was less strange before
c8ea87e4bd950572cba4575e9a62284cebf85ac5, I think.
Pushed with some additional simplification to get rid of the
rather ugly (IMO) PG_USED_FOR_ASSERTS_ONLY variable.
regards, tom lane