Details
Minor
Description
MariaDB [test]> select @@sort_buffer_size; +--------------------+ | @@sort_buffer_size | +--------------------+ | 2097152 | +--------------------+ 1 row in set (0.00 sec) MariaDB [test]> set statement sort_buffer_size = 100000 for set session sort_buffer_size = 200000; Query OK, 0 rows affected (0.00 sec) MariaDB [test]> select @@sort_buffer_size; +--------------------+ | @@sort_buffer_size | +--------------------+ | 2097152 | +--------------------+ 1 row in set (0.00 sec)
If it's not expected to work, there should be an error or a warning.
Percona has a more generic flavor of the problem, where it doesn't work for any combination of variables (https://bugs.launchpad.net/percona-server/+bug/1341438), while in our case it happens when the same variable appears in SET STATEMENT and SET SESSION.
Gliffy Diagrams
Attachments
Issue Links
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
It's an edge case when it comes to the definition of SET STATEMENT, but the common sense suggests that in this situation it isn't supposed to restore the saved value, since it was changed explicitly in <STATEMENT>. It doesn't look meaningful in this simplest form, but imagine that <STATEMENT> is in fact a complicated code, e.g. a stored procedure, and the value changes somewhere deep inside. It would be very unexpected that the whole procedure works smoothly, but the value does not get changed at the end.
That's why it's more reasonable to produce an error saying that a value cannot be changed in <STATEMENT>, although there might be side-effects that should be thought through.
Re-opening so you could re-consider. Please think about it from the user's perspective, not from the implementation side.
IMHO it should be just documented.
Why it does not work?
SET SETSTATEMENT store old value, SET sets new one and SET STATEMENT restore old one.
i.e. SET STATEMENT equal to:
SET @save=@@variable;
<STATEMENT>;
SET SESSION variable=@save;