You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we treat python parameters to be as wide as they can reasonably get. All integer types are treated as INT64, all float types are treated as DOUBLE. However, consider the following script
You would expect for the node to be created; but it isn't. We get the following error
RuntimeError: Parameter 1 has data type INT64 but expects INT32
This is because the way we resolve the type of python parameters right now assigns all integers to INT64 (and all floats to DOUBLE)
What if we implemented a technique that found the narrowest type of our parameters? You can't always make a 64 bit integer into a 32 bit integer, but you can always make a smaller width integer into a larger width integer. I tried it out in the #3090 PR, but it turns out that it doesn't work either.
RuntimeError: Parameter 1 has data type INT8 but expects INT32
The way we expect the type of prepared statement parameters doesn't allow for implicit casting like this.
If we ship the code that does this in #3090 in a release, we must ship corresponding changes that additionally allow for the implicit casting of parameters. This is not ideal, since then it would take a really long time to resolve #3054.
My proposal is that we limit the scope of #3090 to just LIST and MAP parameters, and resolve the above problems in a future set of PRs.
The text was updated successfully, but these errors were encountered:
Currently, we treat python parameters to be as wide as they can reasonably get. All integer types are treated as INT64, all float types are treated as DOUBLE. However, consider the following script
You would expect for the node to be created; but it isn't. We get the following error
This is because the way we resolve the type of python parameters right now assigns all integers to INT64 (and all floats to DOUBLE)
What if we implemented a technique that found the narrowest type of our parameters? You can't always make a 64 bit integer into a 32 bit integer, but you can always make a smaller width integer into a larger width integer. I tried it out in the #3090 PR, but it turns out that it doesn't work either.
The way we expect the type of prepared statement parameters doesn't allow for implicit casting like this.
If we ship the code that does this in #3090 in a release, we must ship corresponding changes that additionally allow for the implicit casting of parameters. This is not ideal, since then it would take a really long time to resolve #3054.
My proposal is that we limit the scope of #3090 to just LIST and MAP parameters, and resolve the above problems in a future set of PRs.
The text was updated successfully, but these errors were encountered: