"Daniel Verite" <dan...@manitou-mail.org> writes: > It looks easy to make the hooks return a bool, and when returning false, > cancel the assignment of the variable.
Yeah, that's about how I was envisioning it too. > I volunteer to write that patch. Thanks. > It would close the hazard that exists today of an internal psql flag > getting decorrelated from the corresponding variable, due to feeding > it with a wrong value, or in the case of autocommit, in the wrong > context. If we want to get to the situation that the variable's value always reflects the internal state, then we should reject deleting the variable too. Currently that's allowed; I was unsure whether we should still permit it, but this line of thought says no. Another issue is what to do in SetVariableAssignHook(). Currently, that's only invoked immediately after creating the variable space so it will always go through the hook(NULL) call, which the hook will think means deletion and then fail for, given the above change. What might be cleanest is to modify SetVariableAssignHook so that it is passed both the initial value and the hook (deleting the separate initial-value-setting calls that currently exist near startup.c:40). If the hook rejects the initial value, that would be grounds for fatal exit. > Also with that, the behavior of ParseVariableBool() assuming "on" > when it's being fed with junk could be changed. Right. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers