How should PRQL deal with operands of different data types?

[vanillajonathan]

from Pets
derive {
  a = "foo" + 7,
  b = "7" + 7
}

In SQL "foo" + 7 became "" while "7" + 7 became 14.

In JavaScript:

• "foo" + 7 becomes "foo7"
• "7" + 7 becomes 77
• "foo" - 7 becomes NaN
• "7" - 7 becomes 0.

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
}

[max-sixty]

In SQL "foo" + 7 became "" while "7" + 7 became 14.

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.

[snth]

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.