Hi Fabien
Hello Pavel,
AFAICR, I had an objection on such new objects when you first proposed
something similar in October 2016.
Namely, if session variables are not transactional, they cannot be used to
implement security related auditing features which were advertised as the
motivating use case: an the audit check may fail on a commit because of a
differed constraint, but the variable would keep its "okay" value unduly,
which would create a latent security issue, the audit check having failed
but the variable saying the opposite.
So my point was that they should be transactional by default, although I
would be ok with an option for having a voluntary non transactional
version.
Is this issue addressed somehow with this ?
1. I respect your opinion, but I dont agree with it. Oracle, db2 has similar or very similar feature non transactional, and I didnt find any requests to change it.
2. the prototype implementation was based on relclass items, and some transactional behave was possible. Peter E. had objections to this design and proposed own catalog table. I did it. Now, the transactional behave is harder to implement, although it is not impossible. This patch is not small now, so I didnt implement it. I have a strong opinion so default behave have to be non transactional.
Transactional variables significantly increases complexity of this patch, now is simple, because we can reset variable on drop variable command. Maybe I miss some simply implementation, but I spent on it more than few days. Still, any cooperation are welcome.
Regards
Pavel