Open Anish9901 opened 2 months ago
I do think we need to do some serious work on our casting functionality, including how to handle casting to/from types we don't explicitly support. However, I think we should avoid getting too deep into that before the beta.
We also need to do some product-level rethinking to figure out how to support this. The reason the current casting functions are somewhat restrictive is to provide a level of safety for the user. In your int -> bool
example above, the reason we don't allow casting anything but 1
to true
is to avoid losing information for the user. If you only cast 1 -> true
and 0 -> false
, you can always recover the original integers. If you cast all non-zero integers to true
, you lose information on the set {0, 1, 2}
. With that said, your jsonb -> bool
example should be implemented, insofar as we're supporting jsonb
. I hope the distinction is clear.
Problem:
mathesar_types
namespace (469 to be exact!!!) we still haven't fully covered all typecasts supported by postgres for the types that mathesar currently supports.Potential solution:
A complelling example:
Type aliases are confusing:
Are we okay with using type names mentioned in pg_type rather than their synonyms in the backend?
(referenced from : https://www.postgresql.org/docs/current/datatype.html)
Getting info about existing typecasting functions provided by postgres: