Alright, I'm convinced my choice for this way of handling undefined was still the right choice, but I'll be happy to add an option to change the default. Do you have a better idea for the name than undefinedAsNull?

That name seems best to me, at least adding the option would help, undefined == null is a common mapping and I think should be default over error but if undefinedAsNull is option I will use it

It's added now and can be used like this in options now { transform: { undefined: null } } . Will be included with the next release

FWIW, I hit this same issue when dealing with multi row "dynamic" inserts.

When specifying the insert manually, it was indeed not such a big inconvenience to replace with null. But taking advantage of the dynamic sql feels a bit different.

The standard I like for my API and TypeScript definitions is to have optional parameters, rather than <type> | null parameters. So this does mean I have to replace undefined when writing to the DB, or use your new "transform" option.

Since I'm not requiring nulls elsewhere in my stack, I don't think it make sense to do so at the DB layer... I prefer to keep things thin and consistent, rather than having transformation between layers.

Anyway, I think what the default should be is a-whole-nother question. I'm happy with the transform config you added.

@aaronyo Do you suggest using the DEFAULT keyword in dynamic insert, when the transform option is missing for instance (kind of implicit { transform: { undefined: sql`DEFAULT` } })? I don't see any other solution for multi row inserts, as the columns list must be the same for all rows