Status Update
Comments
de...@nozzle.io <de...@nozzle.io> #2
I've tried getting around this in the past with stored procedures, but that doesn't return a table, which makes it unusable for this.
de...@nozzle.io <de...@nozzle.io> #3
de...@nozzle.io <de...@nozzle.io> #4
I found some links in ZetaSQL referring to TVFs and optional params. It sort of looks like REQUIRED is hardcoded?
https://github.com/google/zetasql/blob/b7b67f55f8792dc418959f3b60de2d1d00b33c7a/zetasql/public/function.proto#L182 https://github.com/google/zetasql/blob/b7b67f55f8792dc418959f3b60de2d1d00b33c7a/javatests/com/google/zetasql/SimpleCatalogTest.java#L728-L748
Here's a related issue about optional parameters for stored procedures.
va...@google.com <va...@google.com>
ds...@google.com <ds...@google.com> #5
So , It's not a bug , you want a feature to Support optional parameters in UDFs and Table Functions in Bigquery ?
de...@derekperkins.com <de...@derekperkins.com> #6
Correct, this is a feature request, sorry if I mislabeled it, I didn't notice where to set that when creating the issue.
ds...@google.com <ds...@google.com> #7
Hello,
Thank you for reaching out to us with your request.
We have duly noted your feedback and will thoroughly validate it. While we cannot provide an estimated time of implementation or guarantee the fulfillment of the Feature request
Description
I'm trying to simplify BigQuery integration for our customers by hiding complex query logic behind a table function. The problem is that without optional parameters, I can't make any updates without breaking every customer using the function, and they can't use the function without passing in every parameter, even if they're all null.
Here's an example function, where I typically expect 0-3 of the parameters sent in at one time
The docs say "A table function can have up to 256 arguments." Are people really using 256 functions and forcing every single parameter to be sent in every time?
None of these are required, so I would expect NULL values where nothing is explicitly specified.
JSON options workaround
I attempted to support optional parameters using JSON, which technically worked, but caused intense query plans that quickly triggered query planner errors about too many resources.