Petros Angelatos
Petros Angelatos
The internal representation of MONEY in postgres is just an `int64` https://github.com/postgres/postgres/blob/REL_13_3/src/include/utils/cash.h#L17 Then, there is a database global parameter that instructs the parser how many digits are after the decimal...
That's right, it needs to stay the same. Fortunately this is detectable so there isn't a correctness ranger here, only UX danger which we should make clear in the docs
It's not, closing
`ENVELOPE NONE` explicitly discards null values (tombstones). Is this undesirable?
Hm, depends on what this issue is about. This issue (as I understand it) is that `ENVELOPE NONE` drops null values on the floor. This is part of its specification...
Flatness is only one dimension, the other one is null behavior. Here is the full matrix on an imaginary input of a nullable column of type `record(f1: text, f2: int)`...
> The place I get tripped up is that I don't think `Flatten: Y, Discard NULLs: N` should be a valid option. Excellent, I agree! There are two wrinkles however....
For me it's easier to think about in Rust types which I then translate into SQL types. Here is my mental model of the ingestion pipeline as it currently stands...
@dtolnay thank you so much for taking a look! I was planning of posting about this method in the forum soon after improving the explanation. Regarding the issue, I added...