docs: keep enum in core types with CHECK constraint emulation

Enum remains a portable core type:
- MySQL: Native ENUM('a','b','c') inline
- PostgreSQL: VARCHAR with CHECK constraint

The adapter handles the translation automatically, providing
portable enum semantics across backends.

Author: claude

docs/design/multi-backend-plan.md

@@ -64,16 +64,14 @@ The following unsigned types have been removed from `CORE_TYPES`:
 Users requiring unsigned integers should use MySQL native types (e.g., `int unsigned`)
 with the understanding that these are not portable to PostgreSQL.
 
-### 1.2 Enum Removed from Core Types
+### 1.2 Enum Handling
 
-`enum` has been removed from core types due to significant implementation differences:
-- **MySQL:** Inline `ENUM('a','b','c')` in column definition
-- **PostgreSQL:** Requires separate `CREATE TYPE` statement
+`enum` remains a core type with backend-specific implementation:
+- **MySQL:** Native `ENUM('a','b','c')` inline in column definition
+- **PostgreSQL:** `VARCHAR(n)` with `CHECK (column IN ('a','b','c'))` constraint
 
-Users should:
-- Use `varchar(n)` with application-level validation for portable code
-- Use native `enum` type on MySQL (non-portable)
-- Use CHECK constraints on PostgreSQL (non-portable)
+The adapter automatically translates enum definitions to the appropriate backend syntax.
+This provides portable enum semantics while using native capabilities where available.
 
 ### 1.3 Final Core Types
 
@@ -109,6 +107,9 @@ CORE_TYPES = {
 
     # Fixed-point (portable)
     "decimal": ...,  # MySQL: decimal(p,s), PostgreSQL: numeric(p,s)
+
+    # Enum (portable with backend-specific implementation)
+    "enum": ...,     # MySQL: enum(...), PostgreSQL: varchar + CHECK
 }
 ```
 
@@ -117,7 +118,7 @@ CORE_TYPES = {
 | Decision | Rationale |
 |----------|-----------|
 | **No unsigned integers** | PostgreSQL has no unsigned types; cannot be portably emulated |
-| **No enum** | PostgreSQL requires separate type creation; too different to abstract |
+| **Enum via CHECK on PostgreSQL** | PostgreSQL native enum requires separate `CREATE TYPE`; CHECK constraint provides equivalent validation |
 | **No text type** | `varchar(n)` sufficient for most uses; native `text` available per-backend |
 | **datetime (not timestamp)** | Matches Python naming; familiar to scientists; avoids MySQL/PG timestamp confusion |
 | **json → jsonb on PostgreSQL** | Better performance and indexing; key order not guaranteed by JSON spec anyway |
@@ -612,6 +613,7 @@ Test against both databases in GitHub Actions with Python 3.9-3.12.
 | `char(n)` | `char(n)` | `char(n)` | |
 | `varchar(n)` | `varchar(n)` | `varchar(n)` | |
 | `decimal(p,s)` | `decimal(p,s)` | `numeric(p,s)` | |
+| `enum(...)` | `enum(...)` | `varchar` + CHECK | CHECK constraint emulates enum |
 
 ## Appendix B: Native Types (Backend-Specific)
 
@@ -650,4 +652,3 @@ array types (e.g., integer[])
 | `uint16` | No PostgreSQL equivalent | Use `int32` or MySQL native `smallint unsigned` |
 | `uint32` | No PostgreSQL equivalent | Use `int64` or MySQL native `int unsigned` |
 | `uint64` | No PostgreSQL equivalent | Use `int64` (if range fits) or MySQL native `bigint unsigned` |
-| `enum` | Different implementation per backend | Use `varchar(n)` or backend-specific native enum |