I really don't like the fact that BuildInTypeHandlerResolver still references ranges, but without that it's going to make mapping quite difficult (you would have to add range resolver on GlobalTypeMapper) 😭

Wouldn't adding the range resolver to GlobalTypeMapper undo what this PR is trying to do, i.e. allow all the range stuff to get trimmed? If we did that, all the ranges/range handlers would become visible again via the GlobalTypeMapper...

Yeah, this is a crappy situation, but it's a result of us having to resolve mapping stuff on NpgsqlParameter without having an actual connection (e.g. in "static" context); this has always been a pain.

We can consider breaking this, and making the getters on NpgsqlParameter (DbType, NpgsqlDbType, DataTypeName) work only if the parameter is attached to a command and through that to a connection (which has a type mapper). Or we could have a minimum, "default" mapping list on GlobalTypeMapper which doesn't include the ranges, and if the parameter is attached to a connection, go to its resolvers. This way, if you've opted into ranges on your data source, NpgsqlParameter.NpgsqlDbType will know about it, otherwise it won't.

Maybe open a separate issue for thinking about it?

Wouldn't adding the range resolver to GlobalTypeMapper undo what this PR is trying to do, i.e. allow all the range stuff to get trimmed? If we did that, all the ranges/range handlers would become visible again via the GlobalTypeMapper...

Not exactly. We don't need to return a handler from GlobalTypeMapper, just an ability to resolve a mapping by value. We pretty much only need:

1. Dictionary<string, TypeMappingInfo> (where string is dataTypeName)
2. Dictionary<Type, string> (where string is dataTypeName)
3. ValueDependentValueToDataTypeName (and that's because of DataTime.Kind, where we can return either tstzrange or tsrange)

Maybe open a separate issue for thinking about it?

Yeah, sure.

Not exactly. We don't need to return a handler from GlobalTypeMapper, just an ability to resolve a mapping by value.

Hmm.. Right, I remember now that GlobalTypeMapper only deals with type handler factories (which also manage the "static" global mappings). But adding the range resolver factory to the global mapper would also make it available for actually creating the resolver, which is where the trimming problems come in.

We could refactor to split the static mapping thing from the resolver factory (it's a bit ugly that both functions are combined in the factory anyway). At that point we can always add the range global mapping resolver (or whatever we call it), but not have a resolver factory for it without the opt-in...

Anyway, I think it's OK to deal with it after this PR.

Anyway, I think it's OK to deal with it after this PR.

Yeah, we should think about this later.