Sami Imseih <samims...@gmail.com> writes:
>> I don't like that GUC and I would not like this one either. We
>> learned years ago that GUCs that change query semantics are a bad
>> idea, but apparently now we have hackers who need to relearn that
>> lesson the hard way.
> query_id_squash_values has a much weaker argument to exist than a
> guc to control the use of alias vs OID. Why would anyone not want
> to squash the IN list? maybe we should revisit this decision in that thread.
I'm not opining one way or the other on whether squashing an IN list
is desirable. My point is that a GUC is a poor way to make --- or
really, avoid making --- such decisions. The reasons we took away
from previous experiments with semantics-determing GUCs were:
1. The scope of effect of a GUC is seldom what you want for such
things. There are going to be some queries in which you want behavior
A, and some in which you want behavior B, and in the worst case you
want different behaviors in different parts of the same query. It's
really painful to make that happen.
2. Tools that are not entitled to set the value of the GUC are forced
to be prepared to cope with any setting. That can be anywhere from
painful to impossible.
For the specific context of controlling how query jumbling happens,
there's still another problem: the actual statement-merging behavior of
pg_stat_statements will depend on the totality of settings of the GUC
across the entire system. It's not very clear to me what will happen
if different sessions use different settings, much less if people
change the setting intra-session; but I bet a lot of people will find
it surprising. 62d712ecf did no one any favors by marking that GUC
USERSET rather than something that would prevail system-wide.
All of these remarks apply with equal force to anything that changes
the behavior of query-jumbling, no matter the specific details.
regards, tom lane
