On Fri, Jul 3, 2026 at 4:34 PM Jim Jones <jim.jones@uni-muenster.de> 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
