Doug Beatty

It's actually the opposite! What we've described as legacy behavior is working as expected. But what we've said that people _should_ do is **not** working as expected.

Thanks for reporting this along with the root cause and some ideas @ben-schreiber ! ### Root cause Agreed that the cause is the naming conflict between the positional parameter [`args`](https://github.com/dbt-labs/dbt-core/blob/c668846404c78ea7317dc0523b49703c61c9885f/core/dbt/cli/main.py#L50)...

### Options 1. Rename the `args` parameter of `invoke` to something unique (e.g., `invocation_args`) accepting that it will break for anyone using the positional argument as a named parameter. 1....

Hey @tomwphillips thank you for raising this issue and putting up an associated PR (complete with testing!) 🏆 I was able to reproduce the same you described by using your...

Closing and re-opening to re-trigger CI

Good idea! 💡 Let's do it. Just @ mention me when you've got a PR ready.

Thanks for reporting this @jeremyyeo -- we do not want it to be possible to overwrite a pre-existing snapshot and incur the accompanying data loss! It looks to me like...

> So I'm guessing that macro is using the target connection rather than the source db connection to fetch metadata about the source table. Does that seem possible? You might...

> I'm guessing that macro is using the target connection rather than the source db connection to fetch metadata about the source table. Does that seem possible? The query you...

You can override this macro within your project by creating a file like the following: ```sql {% macro redshift__get_columns_in_relation(relation) -%} {% call statement('get_columns_in_relation', fetch_result=True) %} -- The bulk of your...