Kannan Goundan

[@echentw and I are working together on a project that uses Mammoth.] I think the most important thing is for the TS types to be correct. That way I'll get...

Yeah, there are a few strategies to dealing with the `null`/`undefined` confusion: 1. Allow `null` and `undefined` to be used interchangeably (and used together on the same type) and have...

BTW, here's an unsafe workaround to convert all undefined/optional fields to nullable fields: ```typescript type OptionalToNullable = { [K in keyof O]-?: undefined extends O[K] ? NonNullable | null :...

@martijndeh: What is your opinion on using `null` instead of `undefined` to represent Postgres NULLs? I think that matches what the `pg` module does. Tangent: I tried experimenting with changing...

One thing that might become less confusing after switching from `undefined` to `null`: Doing a `UPDATE` to set a field to `NULL`: ```ts await db.update(db.t1).set({a: 'hello', b: undefined}); await db.update(db.t1).set({a:...

Yeah, that should help. However, JS/TS programmers are used to `undefined` being roughly equivalent to a missing field in many contexts. Even if TS introduces types to distinguish, I think...

BTW, this is the workaround I'm using: ```typescript import * as mammoth from '@ff00ff/mammoth'; export function sum(expression: Expression): Expression { const casted = expression as Expression; return mammoth.sum(casted); } ```...

`.notNull()` on its own didn't work because then the field is still required when calling `.insertInto`. But `.default('')` works fine for us, since we're not using Mammoth schema generation/migration.

Just ran into another reason: "pg" doesn't correctly deserialize arrays of enums: https://github.com/brianc/node-pg-types/issues/56 Mammoth has the type information to do it correctly.

The statement about "parsing the text/binary protocol directly" was a bit extreme. I think we might get acceptable performance just passing in a custom value parser, e.g: ```ts import pg...