A CTE can be defined as a table values constructor. In this case the CTE is
always materialized in a temporary table.
If the definition of the CTE contains a list of the names of the CTE
columns then the query expression that uses this CTE can refer to the CTE
columns by these names. Otherwise the names of the columns are taken from
the names of the columns in the result set of the query that specifies the
CTE.
Thus if the column names of a CTE are provided in the definition the
columns of result set should be renamed. In a general case renaming of
the columns is done in the select lists of the query specifying the CTE.
If a CTE is specified by a table value constructor then there are no such
select lists and renaming is actually done for the columns of the result
of materialization.
Now if a view is specified by a query expression that uses a CTE specified
by a table value constructor saving the column names of the CTE in the
stored view definition becomes critical: without these names the query
expression is not able to refer to the columns of the CTE.

This patch saves the given column names of CTEs in stored view definitions
that use them.

Fix:
===
Implemented upstream fix.

commit 7d3d0fc3
Author: He Zhenxing <zhenxing.he@sun.com>

Backport Bug#45852 Semisynch: Last_IO_Error: Fatal error: Failed
to run 'after_queue_event' hook

Errors when send reply to master should never cause the IO thread
to stop, because master can fall back to async replication if it
does not get reply from slave.

The problem is fixed by deliberately ignoring the return value of
slave_reply.

MYSQL_PLUGIN_IMPORT did not work correctly for the RocksDB helper library
rocksdb_aux_lib, because that library was not compiled with
-DMYSQL_DYNAMIC_PLUGIN.

Fix DBUG such that it does not depend on exported data, only on functions
(which do not need MYSQL_PLUGIN_IMPORT decoration)

Use a "getter" function _db_my_assert() instead of DLL-exported variable.

Also, reduce object code duplication by moving more of the DBUG_ASSERT
logic inside the _db_my_assert() function, and add unlikely() and
ATTRIBUTE_COLD hints to ensure that the 'assertion failed' code will
be separated from the main control flow logic. Thus, the compiler can
move the unlikely() code to the end of the compiled function, reachable
via a forward conditional branch, which the processor's branch predictor
could assume 'not taken'.

Fixed 4-byte length characters handled incorrectly.

In mysql-server/commit@f46329044f8618212923bdf52e15d5b464201edc
the InnoDB function btr_cur_open_at_rnd_pos() was corrected so that
it would return a status that indicates whether the cursor was
successfully positioned. But this change was not correctly merged to
MariaDB in 2e814d47.

btr_cur_open_at_rnd_pos(): In the code path that was introduced in
MDEV-8588, properly return failure status.

No deterministic test case was found for this failure.
It was caught after removing the function
page_copy_rec_list_end_to_created_page() in a development branch.
As a result, the fill factor of index trees would improve, and
supposedly, so would the probability of btr_cur_open_at_rnd_pos()
reaching the intentionally corrupted page in the test
innodb.leaf_page_corrupted_during_recovery.
The wrong return value would cause
btr_estimate_number_of_different_key_vals() to wrongly invoke
btr_rec_get_externally_stored_len() on a non-leaf page and
trigger an assertion failure at the start of that function.

- During trx_undo_report_rename(), InnoDB can fail to write undo log
for it if undo log doesn't fit in the undo page. In that case, InnoDB
adds one more undo log page and retry to write the rename undo log.
But the assert is wrong and it doesn't allow to fail even for one time.

Null merge the MDEV-14383 fix; it affects 5.5 only.

there was a SELECT/DELETE race

Re-enable some Galera tests that should have been enabled.

Add client_ed25519.so to debian/libmariadb3.install;
merge e47a143f correctly.

Remove a duplicated #include from wsrep_mysqld.cc.

* do not allow versioned table to be without versioned (non-system) fields
* prohibit changing field versioning, when removing table versioning
* handle CREATE...SELECT as well

The setting innodb_change_buffering_debug=2 was supposed to inject
a crash during change buffer merge. There is no public test for
that functionality, and even if there were, it would be better
to use DEBUG_SYNC to halt the thread that does change buffer merge,
force a redo log flush from another thread, and finally kill the
server externally.

The most likely cause of the crash is that a timer fired, after it was closed.

MSDN documents such a possibility, in the documentation for
CloseThreadpoolTimer() function, and recommends disabling the timer before
calling WaitForThreadpoolTimerCallbacks()/CloseThreadpoolTimer().

The fix follows this recommendation.

Note, that 5.5-10.1 disabled the timer before close, but this code
was lost in threadpool refactoring in 10.2

MYSQL_MAINTAINER_MODE is ERR

Remove debug output,
remove overriding of the Windows C runtime flags(linker warning)
do not add code that depends on restsdk if library is not going
to be linked.

freaking Connect

For Visual Studio generator, use a per-config .def/.lib files with symbols
exported from mysqld.exe

Functions exported from mysqld.exe may differ between debug/optimized
compilation, e.g dbug functions are missing in release config.

InnoDB intentionally (it's a documented behavior) ignores changing of
DATA DIRECTORY and INDEX DIRECTORY for partitions. Though we should
issue warning when this happens.

After SST from master node (the one where event is ENABLED) - you will end up with the event enabled on two nodes, hence it's now being executed twice. It can be solved by comparing event's originator with server_id. if not equal, then change its status to 'SLAVESIDE_DISABLED'

Changes to be committed:
	new file:   mysql-test/suite/galera/r/galera_events2.result
	new file:   mysql-test/suite/galera/t/galera_events2.test
	modified:   sql/events.cc

Test changes only.

Enable after SST script changes.

Try to use more deterministic floating-point operations.
Apparently, 2.2 > 2.2 wrongly holds on many platforms, but
not ppc64le on the compiler used on Red Had Enterprise Linux 8.
The reason could be an infinite binary presentation:
2.2 = 0b10.001100110011…

With t1_f = 2.5 = 0b10.1, t1_f > 2.5 would no longer hold on AMD64.
Let us replace the 2.2 with 2.5 and compare t1_f >= 2.5 in order to
get more consistent results across all platforms.