immudb
immudb copied to clipboard
auto-conversion from varchar to integer and boolean types
This PR provides automatic type conversion based on column specified type and provided varchar value (for integer and boolean types).
e.g.
CREATE TABLE mytable(id INTEGER, name VARCHAR, active BOOLEAN, PRIMARY KEY id);
INSERT INTO mytable(id, name, active) VALUES ('1', 'name1', 'true');
Signed-off-by: Jeronimo Irazabal [email protected]
Kudos, SonarCloud Quality Gate passed!
0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells
No Coverage information
1.4% Duplication
Coverage increased (+0.02%) to 90.659% when pulling bb147f36471f1588cbb6487b41d00de166c836dc on chore_val_parsing into 26df4469afd12508ac9740152e2506a460f09726 on master.
I'm not sure if implicit type conversions are a good idea. IMO it would be better to support explicit cast syntax.
Explicit type conversions caused a lot of issues for MySQL, examples:
- https://developpaper.com/analysis-of-mysql-implicit-conversion/
- https://adamj.eu/tech/2020/03/06/sql-implicit-type-conversion/
I'm not sure if implicit type conversions are a good idea. IMO it would be better to support explicit cast syntax.
Explicit type conversions caused a lot of issues for MySQL, examples:
- https://developpaper.com/analysis-of-mysql-implicit-conversion/
- https://adamj.eu/tech/2020/03/06/sql-implicit-type-conversion/
I think the implicit type conversion included in this PR is safe as it involves decoding a number or boolean from a string. It won't interfere with index calculation or scanning ranges. It provides flexibility when using tables with enough columns from batch files or languages such as python or nodejs and static type checking will also detect illegal values.
It may require some further analysis
@byo do you think this is not to merge?
implicit conversions are already in place. Given the source code changed over time, implementing conversion from varchar and boolean may be directly done over the newest code base