There are in Redshift two types of view, normal and late-binding. When the leader node creates a normal view, it checks at the time of creation `pg_class` for the tables and views being used by the view, and will not create the view if it refers to non-existent tables or views.

Accordingly, external tables cannot be used with normal views because external tables are not present in `pg_class` and so are perceived as being non-existent. To work around this, late-binding views were created, which perform no dependency checking - they do not inspect `pg_class`.

This approach has two major and three minor issues;.

1. The lack of dependency checking means blunders when creating or modifying views lead to faults which can become apparent only at a very different time and in a very different place to a very different person who has no idea what caused the fault

2. There are as the number and complexity of late-binding views increase critical performance problems when enumerating the columns in late-binding views such that it is possible for it to become impossible to enumerate late-binding view columns.

3. A system table function is used to enumerates late-binding view columns and access privileges for this function are incorrectly implemented such that `syslog unrestricted` and `access system table` do not work.

4. The lack of dependency information means no records in `pg_depend` so it is impossible to perform data lineage or inspect dependencies.

5. Late-binding views pollute `pg_class` as they look like normal views (except for a single undocumented difference).

Late-binding views should due to their flaws be used for and only for their one essential purpose, when an external table must be in a view.

https://www.redshiftresearchproject.org/white_papers/index.html

https://www.redshiftresearchproject.org/white_papers/downloads/late_binding_views.pdf

https://www.redshiftresearchproject.org/white_papers/downloads/late_binding_views.html