Re: Prevent conflicting SET options from being set

"Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> writes:
> In this design, our ability to check the conflicting SET or give suggestions
> is contributed by SQL's functionality. This is good I think.

This is out of the question, because we have to be able to execute SET
in environments where we don't have database access nor the ability to
run transactions (eg, postmaster startup). Nor is it obvious that SQL
is the most useful language to make such checks in anyway. For instance
a SQL command wouldn't have access to internal backend state, which it
might need to decide if a setting is valid.

We already have the ability to issue custom messages in assign_hooks,
and I think that's sufficient in practice.

A bigger problem with making cross-variable validity checks is that you
can't really do it per-variable without falling foul of ordering
considerations. For instance, the existing checks in
assign_stage_log_stats and assign_log_stats are ill-considered because
they may reject a postgresql.conf file that turns one variable on before
turning the other off.

regards, tom lane