unytics/bigfunctions

[bug]: `get_latest_partition_timestamp`: has a undeclared variable

shivam221098 opened this issue · 5 comments

Check the bug has not already been reported

Edit function_name and the short error description in title above

  • I wrote the correct function name and a short error description in the title above

What happened and what did you expect?

No matter what table I pass into this procedure, it shows me this error.
image

As you see this bigfunction_result variable is used without its declaration.
image

Hi, I have just encountered this issue too.

To fix it, I added an output parameter in the definition of the function :

CREATE OR REPLACE PROCEDURE get_latest_partition_timestamp (fully_qualified_table STRING, OUT bigfunction_result timestamp)

Now, I would like to add it in the source code, any idea ?

Thanks, But unfortunately BigQuery stored procedures doesn't supports INOUT variables like Postgres. It only supports parameters of IN type, which means you can pass values into the procedure but cannot return values directly through the parameters.

I fixed this and updated a few more things to handle in case of an error.

When the correct table name is passed as an argument
Screenshot 2024-02-07 at 1 27 06 PM
Results:
Screenshot 2024-02-07 at 1 27 19 PM
When table name is not fully qualified
Screenshot 2024-02-07 at 1 27 46 PM

Thanks, But unfortunately BigQuery stored procedures doesn't supports INOUT variables like Postgres. It only supports parameters of IN type, which means you can pass values into the procedure but cannot return values directly through the parameters.

Hi @shivam221098, I have found the feature here, perhaps it is new :

https://cloud.google.com/bigquery/docs/reference/standard-sql/procedural-language#call

That's good to know.
From a BigQuery user perspective, if we implement the above logic then it will require a user to declare a variable then call the procedure then select the declared variable. It will be a three-step process

However, I still don't agree with the current architecture of the procedure because it is still a two-step process. I would say we can do a select bigfunction_result as lastest_partition_timestamp within the procedure so that it will be a one-step process to get the result.

What are your opinions @unytics?