Ideas/plans for additional types #31
Description
Please specify whether your issue is about:
- a possible bug
- a question about package functionality
- a suggested code or documentation change, improvement to the code, or feature request
I like the idea of csvy. I didn't want to invent my own metadata format, so I've been using the yaml file, even though I'm writing the data with different packages (readr, sparklyr, arrow).
However, I realized that the limitation of the column types can get me into trouble. If I have an integer that can't be represented with a 32 bit integer, in R I'll need to store it as a type that can (likely using bit64 or arrow). Those will save out and back in as strings, which is better than several other alternatives of what could happen (that would end up with mangled numbers). But it would be nice to have a better way to deal with them. I imagine that a csvy file with a 64 bit integer saved from python would call that an integer... so from the point of view of having this be a format that is easy to exchange it's not ideal.
Has there been any thought for how to handle extended numeric types for additional precision that we're more commonly have to deal with now?