Hi, Oleksandr, On Sep 06, Oleksandr Byelkin wrote:
+ALTER TABLE db ADD Show_create_routine_priv enum('N','Y') COLLATE utf8mb3_general_ci NOT NULL DEFAULT 'N' AFTER Delete_history_priv; +ALTER TABLE db modify Show_create_routine_priv enum('N','Y') COLLATE utf8mb3_general_ci NOT NULL DEFAULT 'N';
Why two statements?
I also wonder about this pattern, but then I think I got the idea, 1 add the field if it was absolutely absent, 2. fix properties if they were incorrect. But mostly I follow the pattern of other fields adding.
Well, yes, almost. The second statement is, indeed, to fix the column if it existed with incorrect definition. But it's when the definition is *changed in a later version*. For example, if you'd add in 11.3 ALTER TABLE db ADD Show_create_routine_priv enum('N','Y') COLLATE utf8mb3_general_ci NOT NULL DEFAULT 'N' AFTER Delete_history_priv; and, hypothetically, in 11.4 we'd want to use utf8mb4_general_ci, then in 11.4 it'd be two statements: ALTER TABLE db ADD Show_create_routine_priv enum('N','Y') COLLATE utf8mb4_general_ci NOT NULL DEFAULT 'N' AFTER Delete_history_priv; ALTER TABLE db modify Show_create_routine_priv enum('N','Y') COLLATE utf8mb4_general_ci NOT NULL DEFAULT 'N'; where the first statement would work for upgrades from 11.2 and below, and the second statement would work for upgrades from 11.3. But there's no need to do that when you add a new column for the first time.
@@ -9250,7 +9255,7 @@ static uint command_lengths[]= 11, 5, 7, 17, 14, 8, 15, 16, 15, 23, 24, 12, - 13, 13 + 13, 13, 19
May be you'll change these two arrays into one of LEX_CSTRING's ? in a separate commit, of course.
OK
No, please don't, Vicentiu replied that he already did it the DENY branch. Regards, Sergei VP of MariaDB Server Engineering and security@mariadb.org