Jeremy Cohen

@mikaelene There is retry logic within the connection object for some adapters, notably dbt-bigquery. [Here](https://github.com/fishtown-analytics/dbt/blob/344a14416d22f0cfbeb56b9904092c8a4f38b1fc/plugins/bigquery/dbt/adapters/bigquery/connections.py#L42-L47) we define which errors are intermittent, unlikely to recur, and thereby "retryable". [Here](https://github.com/fishtown-analytics/dbt/blob/344a14416d22f0cfbeb56b9904092c8a4f38b1fc/plugins/bigquery/dbt/adapters/bigquery/connections.py#L559-L563) is where...

I think we've got one for just the thing: https://github.com/dbt-labs/dbt-redshift/issues/96 (though the fix would more likely come in https://github.com/dbt-labs/dbt-core/issues/5022)

> I haven't seen this error message before, maybe @jtcohen6 could explain. It seems it has to do with partial matches due to quoting differences? this might constitute a breaking...

+1 to using `{{ relation }}` instead of concatenating. Check out how we did this same thing in `dbt-spark`: - [SparkIncludePolicy](https://github.com/fishtown-analytics/dbt-spark/blob/2f7c2dcb419b66d463bb83212287bd29280d6964/dbt/adapters/spark/relation.py#L16-L20), which turns off `database` - That policy is then...

Option 1 doesn't sound crazy to me. You could define a special method on `SQLServerRelation`, something like `index_render`, and then call `{{ full_relation.index_render() }}` as needed. It's fewer moving pieces...

@ueshin `dbt-spark` is raising this explicit error [in the `get_catalog` method here](https://github.com/dbt-labs/dbt-spark/blob/7fbd82c8716bcaa9478ec779a3efc00e4ac3281a/dbt/adapters/spark/impl.py#L291-L297 ), because it: - Operates on one schema at a time (today by running `show table extended in...

@mcfuhrt I think we'll need some more configuration details to get to the bottom of this one. Are you able to reproduce the error in a simpler project, with the...

Thanks for this @mcfuhrt! I was able to reproduce the error, using the example you've provided. It looks like this line in your source definition is to blame: ```yml quoting:...

@mcfuhrt For adapters with "two-tiered" namespacing, the top-level tier (`database`) will always be `null`. This should be totally consistent, minus the issue you uncovered around quoting. I don't imagine this...

I'm able to reproduce this locally with the latest `dbt-databricks` + `dbt-core`. I'm trying to figure out where in the methods called by `docs generate` a `DatabricksRelation` is being passed...