My "hard" opinion is that providing an unsafe by default feature (i.e. which works as in some particular cases, but may fail silently if the transaction fails), especially for a security related use case which motivates the whole feature addition, is a very bad idea for the product. If a committer likes it anyway, good for you.
I respect to your opinion and I understand - I have a similar strong opinion on packages in Postgres. In this case I prefer a common implementation - and common expectation.
When some feature is PostgreSQL original, then we can design how we can. But when we implement some feature that exists already, then we should to respect some previous, older major implementation.
The great example is our implementation of OUT parameters in PL. The idea is great - modern languages use it Golang, Rust. But in PL area is unique, different. One from significant issues migrations to Postgres, Postgres adoptions is this small feature.
The people who is working with stored procedures doesn't expect XA behave, overhead when they working with some objects named "variables". We can implement XA support for variables, ale I don't think so default should be XA. Only few cases where variables can be used are are XA sensitive.
A syntax can be designed very verbose, so anybody can see and should to choose expected behave of variables
CREATE [ { TEMPORARY | TEMP } ] [ { TRANSACTIONAL | XA } ] VARIABLE [ IF NOT EXISTS ] varname datatype [ DEFAULT default_expression ] ;
Regards
Pavel
Regards
Pavel
Other opinions I expressed on the thread are somehow "softer", i.e. even if I think that there are better (simpler, easier) alternatives, these are only alternatives.