Just tested it locally and also locally in SiS and everything seems to work as expected!

@lukasmasuch that's a good point. In our documentation, we provide an example that seems to contradict with the Snowflake documentation.

The example

indicates that you can use a default connection but set, for example, the username.
But the Snowflake doc states

If you choose to rely on a default connection, you cannot override connection parameters, such as username, database, or schema.

So you cannot leverage the default connection by providing the connection name snowflake but still override fields such as user. I believe we should update that example and state that this is only possible when using in conjunction with streamlit secrets (because this would trigger one if-branch before the modified one).
The Snowflake docs only provide examples where no args are given in order to load the default values, so I think we should adhere to that pattern.

Ok, but sounds like this is not supported only if there is a default connection. In other cases, you can use kwargs with the snowflake connection. cc @sfc-gh-dmatthews

yep! then you wouldn't write st.connection("snowflake") but st.connection("my_connection_name", type="snowflake", **your_kwargs) which would trigger the other code path and pass the your_kwargs.

Okay, so I just need to add a warning to the examples that if you have configured a default snowflake connection, you must specify a connection name (not "snowflake") to use kwargs or do anything other than use that default connection as-is?

If you have a secret [connections.snowflake] then that one is used if you use st.connection("snowflake") and you can pass extra arguments.
Otherwise, if you don't have that secret and have configured a default connection and want to use it, you just provide st.connection("snowflake") with no extra arguments.
Or use st.connection("my_connection", type="snowflake") with additional kwargs.