Option private_key does not work when launching SnowSQL about django-snowflake

[timgraham]

Thanks. I would keep this open because it's a valid bug. I hope we can solve it one way or another in the short-term (maybe in the next month-ish), so I don't think we need to document it in the README, which is more for longer term limitations.

One way to document it would be to change the code to raise NotSupportError when trying to run dbshell if private_key is specified. That's probably not worthwhile in the short term though.

Let's see what response snowflakedb/snowflake-connector-python#1565 gets. If it's not accepted, we could consider adding private_key_file and private_key_passphrase options specific to this project.

[timgraham]

I think I would first raise the issue with Snowflake Connector for Python and ask if they would be willing to add private_key_file and private_key_passphrase options. It's not clear to me whether such boilerplate is best placed in this project as seems likely useful for other connector users.

It's possible decrypting the key as documented may not be generalizable, e.g. could a key have a different format or encoding? But it seems some form of general decryption was implemented in snowsql since it only accepts a path?

[sfc-gh-hachouraria]

I've filed a feature request at snowflakedb/snowflake-connector-python#1565 referencing this issue.

Should we formally document the current limitation around using the specific combo of private_key + manage.py dbshell (the Python interpreter via manage.py shell would work, and this isn't a blocker)?

If not, we can close this issue and revisit in the future depending on the feature being accepted.