Update wording

[runleonarun]

What are you changing in this pull request and why?

Hey @jtcohen6 or @dbeatty10! @kbrock91 requested we change this a tiny bit. Can you let me know if this wording is OK? I also took the passive voice out to make the English a little simpler.

She also asked if we have a list / matrix available of which platforms support constraints and whether they are supported and/or enforced ? Or a link to a page with that info?

Checklist

• Review the Content style guide and About versioning so my content adheres to these guidelines.
• Add a checklist item for anything that needs to happen before this PR is merged, such as "needs technical review" or "change base branch."

[netlify]

✅ Deploy Preview for docs-getdbt-com ready!

Name	Link
🔨 Latest commit	4eac9b2
🔍 Latest deploy log	https://app.netlify.com/sites/docs-getdbt-com/deploys/6449c14aac14070008189abe
😎 Deploy Preview	https://deploy-preview-3244--docs-getdbt-com.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[jtcohen6]

@runleonarun This change in wording is good by me!

She also asked if we have a list / matrix available of which platforms support constraints and whether they are supported and/or enforced ? Or a link to a page with that info?

Yes, great idea! I made a table of these a few months ago, to guide the implementation for the DWH adapters that we maintain: dbt-labs/dbt-core#7067 (comment).

• How do you think we should make that extensible, for all the other DWHs?
• Do you want to do that as part of the scope of this PR, or should we open a new issue?

[dbeatty10]

If we had adapter-specific feature support matrix pages similar to this, we could add a table for dbt model contract constraints.

Along the lines of dbt-labs/dbt-core#7067 (comment), here's some brainstorming on representing how different constraints will behave per adapter:

constraint type	dbt-redshift
not_null	🌕 supported & enforced
primary_key	🌗 supported; not enforced
foreign_key	🌗 supported; not enforced
unique	🌗 supported; not enforced
check	🌑 not supported

constraint type	dbt-redshift
not_null	🌕 supported & enforced
primary_key	🌓 supported; not enforced
foreign_key	🌓 supported; not enforced
unique	🌓 supported; not enforced
check	🌑 not supported

constraint type	dbt-redshift
not_null	🌕
primary_key	🌗
foreign_key	🌗
unique	🌗
check	🌑

constraint type	not_null	primary_key	foreign_key	unique	check
dbt-redshift	🌕 supported & enforced	🌗 supported; not enforced	🌗 supported; not enforced	🌗 supported; not enforced	🌑 not supported

constraint type	not_null	primary_key	foreign_key	unique	check
dbt-redshift	🌕	🌗	🌗	🌗	🌑

constraint type	not_null	primary_key	foreign_key	unique	check
dbt-redshift	✅	🟡	🟡	🟡	❌

constraint type	not_null	primary_key	foreign_key	unique	check
dbt-redshift	✅	🟧	🟧	🟧	❌

constraint type	not_null	primary_key	foreign_key	unique	check
dbt-redshift	✅	⚠️	⚠️	⚠️	❌

constraint type	not_null	primary_key	foreign_key	unique	check
dbt-redshift	✅	🔄	🔄	🔄	❌

[runleonarun]

How do you think we should make that extensible, for all the other DWHs?
Do you want to do that as part of the scope of this PR, or should we open a new issue?

Such good questions. I like Doug's suggestions, so we could maybe riff on them in the issue I opened to follow-up with this. #3282

[runleonarun]

Merging because this wording was approved by Jeremy earlier!