On 2025-Mar-25, Tom Lane wrote:
> Christoph Berg <myon@debian.org> writes:
> > For 2), Tom said that configurability is 1) often much less useful
> > than originally planned, and 2) tools have to cope with both settings
> > anyway, making implementing them harder. Plus, switching at run-time
> > makes the result even less predictable.
>
> To clarify that last bit: if some clients run with the GUC on and some
> with it off, you have a mess. Even statements that are completely
> identical will have different query IDs under the two settings.
True.
> If this GUC sticks around, it should be at least PGC_SUSET (on
> the analogy of compute_query_id) to make it harder to break
> pg_stat_statements that way.
I have no problem making it superuser-only, and I can see making "on" be
the default. I am not opposed to removing it completely either, if we
really think that the current behavior is no longer useful for anybody.
Earlier in the discussion, other possible values for the option were
suggested, such as a way to distinguish arrays that had "lots" (say,
hundreds or more) of entries from arrays that were "small". That could
be selected by the user (or site admin) using this GUC, though there was
no agreement on exactly what that would be. During the FOSDEM 2024
development meeting there was a general dislike of this idea, which
AFAIR was mostly predicated on the displayed query no longer being valid
SQL. But now that we've chosen a format that uses SQL comments, this is
no longer a problem, so I think we haven't closed that door yet. But we
may still find out that no user cares about this.
Dmitry?
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"Los dioses no protegen a los insensatos. Éstos reciben protección de
otros insensatos mejor dotados" (Luis Wu, Mundo Anillo)
