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); Regards, -- Fujii Masao
