Conversation
|
|
Hydrocharged
left a comment
There was a problem hiding this comment.
Conceptually I don't mind the change as long as the internal encodings match the expected behavior of Postgres, and this isn't always true for seemingly equivalent types. I mentioned the decimal.decimal to pgtype.Numeric conversion as an example in the DM, as val.DecimalEnc will surely use the wrong internal representation (being built for decimal.Decimal). There are other things that one may not think about as well, such as infinity and NaN ordering for the floating point values, since those are invalid in MySQL (AFAICT) but valid in Postgres, so are we handling that properly?
This is ignoring stuff regarding how index ordering behaves (although we don't yet support index ordering and maybe we never will and just always take the speed hit, but worth mentioning). Maybe we implement this stuff using special Doltgres-only variations of built-in encodings for types where we need something different. For example, val.Int16Enc for the "default" case, val.Int16NFDescEnc if we're storing in descending order with nulls first.
Technically we could do that for all built-in types, and then user-defined types take the slower extended type path since they'll be less used in the average case (or we even specialize known stable encodings like pgvector).
| Query: "SELECT DISTINCT ON(v3) v1 FROM test2;", | ||
| Expected: []sql.Row{ | ||
| {1}, | ||
| {2}, |
There was a problem hiding this comment.
Why was this changed? I just ran this against a Postgres instance and got the original result of 1.
| // case "json", "jsonb": | ||
| // return val.JSONAddrEnc | ||
| case "oid", "regclass", "regproc", "regtype": | ||
| return val.Int32Enc |
There was a problem hiding this comment.
These use id.Id, which is a string, so that's probably why some of the tests are failing.
Companions:
dolthub/dolt#10826
dolthub/go-mysql-server#3512