-
Notifications
You must be signed in to change notification settings - Fork 250
How should PRQL deal with operands of different data types? #4305
-
from Pets derive { a = "foo" + 7, b = "7" + 7 }
In SQL "foo" + 7 became "" while "7" + 7 became 14.
In JavaScript:
"foo" + 7becomes"foo7""7" + 7becomes77"foo" - 7becomesNaN"7" - 7becomes0.
In Python you get a TypeError.
Implicit type conversion can be convenient but it can also be a source of bugs. Explicit type conversions could be an alternative.
from Pets derive { a = "foo" + (7 | str), b = ("7" | int) + 7 }
Beta Was this translation helpful? Give feedback.
All reactions
Replies: 2 comments
-
In SQL
"foo" + 7became""while"7" + 7became14.
Oh gosh!! Nice example.
Yes, I think raising an error where possible makes sense with these.
There's an issue of "values in the columns act differently to literal values" — i.e. a + 7 would work even when a contains "foo" (unless we know the type of the column).
But I don't think this presents the same problems as #4289, since I don't think there's ever a reason to need "foo" + 7 to work, and casting is always possible.
Beta Was this translation helpful? Give feedback.
All reactions
-
In the Playground, DuckDB does throw errors for both of these;
from [{a=1}] select { b = "foo" + 7, c = "7" + 7, }
However it would be great if PRQL was strongly typed and could point this out to you ahead of time as well as in the LSP.
Beta Was this translation helpful? Give feedback.
All reactions
-
👍 1