MDEV-37220 Allow UPDATE/DELETE to read from a CTE

[mariadb-RexJohnston]

• The Jira issue number for this PR is: MDEV-37220

Description

We extend from the SQL standard to match the functionality of other databases allowing the inclusion of a CTE definition prior to update and delete statements. These CTEs are currently read only, like other derived tables, so cannot have their columns updated in updates set clause, nor have rows removed in the delete statement.

Release Notes

Allow CTE definitions prior to UPDATE and DELETE statements.

How can this PR be tested?

mtr main.cte_update_delete

If the changes are not amenable to automated testing, please explain why not and carefully describe how to test manually.

Basing the PR against the correct MariaDB version

• This is a new feature or a refactoring, and the PR is based against the main branch.
• This is a bug fix, and the PR is based against the earliest maintained branch in which the bug can be reproduced.

PR quality check

• I checked the CODING_STANDARDS.md file and my PR conforms to this where appropriate.
• For any trivial modifications to the PR, I am ok with the reviewer making the changes themselves.

[spetrunia]

please use more descriptive names.
$empty_t3, $fill_t3 ?

[spetrunia]

Can't believe test coverage for this one is not present but I don't see it anywhere:

create table t1 (a int, b int , c int);
insert into t1 select seq, seq, seq from seq_1_to_100;
with T as (select * from t1) delete from T where a<3;
ERROR 1288 (HY000): The target table T of the DELETE is not updatable

Ok...

with T as (select * from t1) update T set a=3;
ERROR 1054 (42S22): Unknown column 'a' in 'SET'

I'm not sure how we arrive at this error here.

MariaDB [test]>  with T as (select * from t1) update T set T.a=3;
ERROR 1054 (42S22): Unknown column 'T.a' in 'SET'

[mariadb-RexJohnston]

MariaDB [test]>  with T as (select * from t1) update T set T.a=3;
ERROR 1054 (42S22): Unknown column 'T.a' in 'SET'

What is happening here is that because name resolution is performed on the field T.a at the end of Multiupdate_prelocking_strategy::handle_end() (it calls setup_fields), it is searching through the definition of T prior to setup_wild() being performed on the select_lex associated with the derived table.

For a derived table, this limitation is caught in the parser. For a view, we do not store any wildcards in the definition.

I'm currently looking for the simplest fix.

[spetrunia]

The patch makes use of LEX::save_list. I was concerned what other users are there.

LEX::save_list should get a comment:

 This is used by 
  - Parsing CREATE TABLE t0 (...) UNION = (t1, t2, t3)
  - CTEs for DELETE, see mysql_init_delete(). 

I'm also wondering if we could move save_list to somewhere where it's clear its lifetime is parser:

struct LEX {
  ...
   struct { 
       SQL_I_List<TABLE_LIST> save_list;
   } parser_state;

and then make debug build wipe out lex->parser_state after parsing is finished...

[grooverdan]

and then make debug build wipe out lex->parser_state after parsing is finished

MEM_UNDEFINED(&lex->parser_state, sizeof(lex->parser_state)); so MSAN builders can catch what's trying to access it rather than Debug having a working build for unknown reasons.