Explain early-binding views in Postgres and include our pro-tips

[dbeatty10]

Contributions

• I have read the contribution docs, and understand what's expected of me.

Link to the page on docs.getdbt.com requiring updates

https://docs.getdbt.com/reference/resource-configs/postgres-configs

What part(s) of the page would you like to see updated?

Add new section called "Early binding views" between "Performance optimizations" and "Materialized views", just like the docs for dbt-redshift.

The new context might look like this:

### Early binding views
Unlike Redshift, Postgres does not support [views](https://docs.getdbt.com/terms/view) unbound from their dependencies ([late binding views](https://docs.aws.amazon.com/redshift/latest/dg/r_CREATE_VIEW.html#late-binding-views)). In practice, this means that if upstream views or tables are dropped with a cascade qualifier, any view that depends on it will get dropped as well.

To avoid having data that is unavailable to consumers during a dbt build, our recommendation is to use the [`table` materialization](https://docs.getdbt.com/docs/build/materializations#table) for any relations that are exposed to consumers.

Key insight

When a table is recreated in Postgres, any views that depend upon it will be deleted automatically and will need to be recreated. They will be unavailable in the meantime and data access attempts will return a database error.

This is because postgres only supports early-binding views (as opposed to most other cloud data warehouses). As a derivative of Postgres, Redshift also uses early-binding views, but it allows late-binding as a configuration option. BigQuery, Spark, and Databricks only have late-binding views.

Our recommendations

• In Redshift, use late-binding views across the board
• In Postgres, use tables (rather than views) for any data sets that are exposed to consumers

Additional information

No response