Meine Forschung steht im Ticket [das] daraufhin ein anderer Bearbeiter zugeteilt bekommen hat. Der hat aber auch so ~400 weitere Bugs zugeteilt.
Bzgl. Priorität ist der obengenannte Fehlerreport allerdings schon an 55. Stelle! 
(45. Stelle, wenn man die Einträge ignoriert, an welchen derzeit nicht gearbeitet wird)
Wird also noch dieses Jahr gelöst? *scnr*
Also mittlerweile kann ich schon ziemlich genau nachvollziehen was da passiert ist.
Beim Union wird entschieden welchen Datentyp das Ergebnis hat, dazu muss jedes Feld des Unions überprüft werden und der Datentyp des größten Feldes muss zum Ergebnisdatentyp gemacht werden (sind ja zwei rows in einer column!). Früher hat das die Funktion 'Item_type_holder::join_types()' gemacht. Die hat man aber mit diesem commit rausgenommen, weil man dachte man hat das so an anderer Stelle doch auch schon: https://github.com/MariaDB/ser…a41e541f3149a917850f4e2fb
(in Mysql ist die Funktion übrigens noch drin...)
Jetzt sollte die Funktion 'st_select_lex_unit::join_union_item_types()' das ganze übernehmen. Diese wird aufgerufen und ermittelt fürs erste Feld den Typ Varchar (stimmt) aber fürs zweite Feld auch Varchar (hier sollte es mediumblob sein!). Somit wird der Text in einen Varchar gepresst. Dieser hat aber nur zwei Bytes für seine Maximallänge, deshalb kommt nicht der ganze Text im Ergebnis an.
Ich denke ich konnte damit ziemlich genau zeigen wo das Problem eigentlich liegt und damit (vielleicht) dem aktuellen Bearbeiter etwas helfen.
Ist natürlich auch gut möglich dass die schon lange wissen dass sie es da verkackt haben und bislang nur keine Lust hatten das richtig zu reparieren.
Gibt ja auch nen zweiten Fall welcher wohl das gleiche Problem hat: https://jira.mariadb.org/browse/MDEV-17226
Fehler ist weiterhin vorhanden in:
10.6.7-MariaDB-2ubuntu1
10.8.3-MariaDB-1:10.8.3+maria~jammyYay!
PS: Fehler tritt nicht auf in:
Mysql 8.0.29-0ubuntu0.22.04.2Immerhin ist der Fehler nun schon an 34. Stelle (sic!) in der Liste der zu bearbeitenden, nach Priorität geordneten Fehler. Könnte 2025 also in den "Top 10" landen! 
Wird also noch dieses Jahr gelöst? *scnr*
Könnte 2025 also in den "Top 10" landen!
Gerade noch 2022 und Platz 24. Könnte stimmen mit 2025 
Gerade noch 2022 und Platz 24. Könnte stimmen mit 2025
MySQL ist nicht besser, nur langsamer in der Entwicklung. Da musst du froh sein, wenn sie den Bug bis 2025 überhaupt schon eingebaut haben. 
Hab mal nen Bug gefiled: https://jira.mariadb.org/browse/MDEV-22923
Wir werden sehen, in 2 Tagen ist das behoben oder ich werde als Idiot beschimpft.
Hoffentlich...
LOL: Priorität: Schwer (war: Kritisch)
Das wird nichts mehr in diesem Jahrzehnt 
Ja, auch gerade gesehen. Naja, die sind ja jetzt an der Börse, jetzt wird sicherlich alles besser! 
