On 2020-Mar-10, Tom Lane wrote:
> I agree that something ought to be done here, but I'm not sure that
> this is exactly what. It appears to me that there are three related
> but distinct behaviors under discussion:
>
> 1. Truncation of bind parameters returned to clients in error message
> detail fields.
> 2. Truncation of bind parameters written to the server log in logged
> error messages.
> 3. Truncation of bind parameters written to the server log in non-error
> statement logging actions (log_statement and variants).
>
> Historically we haven't truncated any of these, I believe. As of
> ba79cb5dc we forcibly truncate #1 and #2 at 64 bytes, but not #3.
> Your patch proposes to provide a SUSET GUC that controls the
> truncation length for all 3.
The reason I didn't change the other uses was precisely that it was
established behavior, but my opinion was that truncating them would
be better, now that we have code to handle doing so.
Maybe it would make sense to always log complete parameters for error
cases when that feature is enabled, and have the GUC only control the
lengths logged for non-error cases?
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services