dbt-materialize: more gracefully handle contracts on unknown types

[benesch]

Backport dbt-labs/dbt-core#8887 to make data contracts work correctly with custom PostgreSQL types that are unknown to dbt/psycopg2. The error messages are bad when contract validation on such types fails, but the contracts fundamentally work, which is a big improvement.

See comments within the patch for details.

Motivation

• This PR fixes an issue reported by a customer on Slack.

Checklist

• This PR has adequate test coverage / QA involvement has been duly considered.
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
• This PR includes the following user-facing behavior changes:
  • n/a

[morsapaes]

Thanks again for tying this up in a bow, @benesch!

[morsapaes]

Suggested change

	* Backport [dbt-core #8887](https://github.com/dbt-labs/dbt-core/pull/8887) to
	to unblock users using any custom type with data contracts.
	* Backport [dbt-core #8887](https://github.com/dbt-labs/dbt-core/pull/8887) to
	unblock users using any custom type with data contracts.

[benesch]

Oops, thanks!

[morsapaes]

Nice impersonation.

[benesch]

🫡

[morsapaes]

Suggested change

	# `data_type_code_to_name`` method for details. We may be able to remove
	# `data_type_code_to_name` method for details. We may be able to remove

[benesch]

Thanks, fixed.

[morsapaes]

Unfortunately, this patch doesn't generalize due to #17870. After fetching the columns and data types for the query in the model, dbt will also fetch the columns and data types declared in the .yml file (default__get_empty_schema_sql) using:

cast(null as {{ col['data_type'] }}) as {{ col_name }}{{ ", " if not loop.last }}

This will result in a cannot reference pseudo type error:

create temporary view __dbt_sbq19 as
   select * from (
       select

     cast(null as record) as rd
   ) as __dbt_sbq

I'll work on a patch to the patch, but wanted to raise in the meantime so we don't point users with this issue at v1.7.2.

[benesch]

I'll work on a patch to the patch, but wanted to raise in the meantime so we don't point users with this issue at v1.7.2.

Hrm, what's the workaround though? It seems like we might just need to fix this one Materialize side. The way we handle casts to record is at variance with PostgreSQL.

[morsapaes]

I was trying to think of something smart, but...is it easy enough a fix that we could ship it in the next release?

[benesch]

Probably not. Lemme start a Slack conversation.

[benesch]

For posterity, Slack conversation here: https://materializeinc.slack.com/archives/C0414ER457U/p1702931272032539