On 03/07/2026 17:46, Fujii Masao wrote: > On Fri, Jul 3, 2026 at 4:34 PM Jim Jones <[email protected]> wrote: >> +1 >> Nice additions -- the feature gap is obvious, IMHO. >> >> Are you planning to work on it? I'm drowning in work right now and can >> only jump on it next week. > I don't have plans to work on those at the moment, so please feel free > to take them on if you have time! > > >> I'm not so sure about this one. At this point, isn't "query" already \0 >> terminated? I'm also wondering if it could affect pg_mbcliplen() down >> the road, since strnlen() can return a different value >> (log_statement_max_length + MAX_MULTIBYTE_CHAR_LEN) on large queries -- >> not tested yet. > Yes, "query" should already be NUL-terminated here. The reason for > using strnlen() is not to handle an unterminated string, but to avoid > scanning the entire query when it's very large and we only need to > know whether it exceeds log_statement_max_length. > > I think it's fine to pass the bounded length to pg_mbcliplen(). > It only needs enough input to find a multibyte-safe clipping point at > or before log_statement_max_length, i.e., it doesn't need the full > query length. The extra MAX_MULTIBYTE_CHAR_LEN bytes provide enough > lookahead to handle a multibyte character boundary correctly. > > - query_len = strlen(query); > + query_len = strnlen(query, > + (size_t) log_statement_max_length + MAX_MULTIBYTE_CHAR_LEN);
All right, thanks for the explanation. I'll give it a try next week. Have a nice weekend! Best, Jim
