[CT-2441] [Feature] Support expression for all constraint types

[jtcohen6]

For model-level and column-level constraints, only check and custom constraints will include the expression field in their templated DDL.

I think all constraints should support the custom expression field. This is:

• Relevant to support additional options on some constraint types — e.g. UNIQUE NULLS NOT DISTINCT instead of UNIQUE, the user could configure with expression: nulls not distinct
• Necessary for foreign key / references constraints — although the user can't really do things like stick ref in here, since we kicked that out of scope (rationale: [CT-1922] Support 'constraints' as a model-level property #6754 (comment)), so I wouldn't consider these constraints high-priority

This is on me - I didn't do a good job of making this clear in the revised spec (#7066)! The words I used were free for all, which really had two meanings:

• the user is free to put whatever text they want in here
• the user is free to define this for any constraint type, and expect it will propagate

---

I'm opening this issue to track the gap, but the more I write, the less I feel this is something we need to go do right away.

• While primary and foreign key constraints are nice for annotation (e.g. metadata to power ERD diagrams), they aren't enforced by the majority of analytical data platforms. In practice, their precise functionality is irrelevant for the vast majority of dbt users.
• There is a valid workaround: users can always opt for the type: custom constraint, which is just a free text entry.

---

Relevant methods:

dbt-core/core/dbt/adapters/base/impl.py

Line 1327 in ada8860

def render_raw_columns_constraints(cls, raw_columns: Dict[str, Dict[str, Any]]) -> List:

dbt-core/core/dbt/adapters/base/impl.py

Line 1384 in ada8860

def render_model_constraint(cls, constraint: ModelLevelConstraint) -> Optional[str]: