-
Notifications
You must be signed in to change notification settings - Fork 427
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: Case Sensitive snowflake_procedure_sql
variables
#3298
Comments
snowflake_procedure_sql
argument syntax errorsnowflake_procedure_sql
argument casing
snowflake_procedure_sql
argument casingsnowflake_procedure_sql
variables
snowflake_procedure_sql
variablessnowflake_procedure_sql
variables
Hi @jdoldis 👋 You are right - this happens because arg_name is quoted (by the provider) and is actually lowercase in this example, but it is not quoted in the definition. The behavior is expected. Please either use uppercase I think this is related to all resources with fields like |
Perfect, thanks @sfc-gh-jmichalak ! |
Hey @jdoldis. We have released v1.0.1 on Friday. We added clarifications in the migration guide and the registry docs. Please check if the docs are clearer now. |
Looks great @sfc-gh-asawicki , will close this issue thanks 🙂 |
Terraform CLI Version
1.9.8
Terraform Provider Version
0.100.0
Company Name
No response
Terraform Configuration
Category
category:resource
Object type(s)
No response
Expected Behavior
CALL <database>.<schema>.TEST_PROCEDURE('test', 'test');
returnsSuccess
.Actual Behavior
CALL <database>.<schema>.TEST_PROCEDURE('test', 'test');
gives errorError: invalid identifier 'SCHEMA_NAME' (line 13)
.Steps to Reproduce
Create the resource with the above config, and run
CALL <database>.<schema>.TEST_PROCEDURE('test', 'test');
.How much impact is this issue causing?
Medium
Logs
No response
Additional Information
It seems the arguments in the procedure signature are defined with double quotes. The create statement from the above configuration -
I verified on the console that removing the double quotes from the procedure signature and then calling returns
Success
as expected.In addition, it seems quoting
schema_name
andtable_name
in the procedure definition of the resource fixes the issue -I don't think this was necessary in previous versions of the provider, as calling the procedure worked previously.
Would you like to implement a fix?
The text was updated successfully, but these errors were encountered: