Table schema stores unnormalized expression for default values, which leads to unexpected behaviors.

[nicktobey]

When creating a table with default values, we store the default value expression as a string in the table schema.

So for example, CREATE TABLE foo (f float default '1.0'); stores the string '1.0' in the table schema.

However, SHOW CREATE TABLE normalizes these values before displaying them, so SHOW CREATE TABLE foo; produces the following output:

+-------+------------------------------------------------------------------+
| Table | Create Table                                                     |
+-------+------------------------------------------------------------------+
| foo   | CREATE TABLE `foo` (                                             |
|       |   `f` float DEFAULT '1'                                          |
|       | ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_bin |
+-------+------------------------------------------------------------------+

This leads to several unexpected results, primarily occurring if the table is dropped and recreated with the generated CREATE TABLE statement.

• dolt status shows that the table has been modified, but dolt diff does not show any differences:

% dolt status
On branch merge

Changes not staged for commit:
  (use "dolt add <table>" to update what will be committed)
  (use "dolt checkout <table>" to discard changes in working directory)
	modified:         foo
% dolt diff
diff --dolt a/foo b/foo
--- a/foo
+++ b/foo
%

• The two versions of the table schema have different hashes, which means that they are considered different for the purposes of merging. This may lead to unresolvable merge conflicts.

I don't see any benefit to storing these default values in an unnormalized state. This is especially true if we normalize them before displaying them to the user, since it makes it nearly impossible for the user to tell how the two schemas differ.