Originally I thought of the resolvers list as always being quite small, e.g. how many plugins could there possibly be.. I'm not sure if we have places where perf would be problematic if this list starts growing; IIRC we should only actually access the resolvers for NpgsqlDbType/Type that we haven't seen before (we cache). Maybe on connection startup (when the cache is empty) this could in theory become problematic, if the user has e.g. 200 enums/composites or something.

To be on the safe side, we could have a single resolver handle them all; though if you're convinced this doesn't matter I'm OK with it.

Maybe on connection startup (when the cache is empty) this could in theory become problematic, if the user has e.g. 200 enums/composites or something.

You do have a point here. A few of my thoughts below:

1. With 200+ enums/composites a cold start will be slow no matter what we do (as it implies a big codebase).
2. One way to go around this is to implement resolver sorting. Since enums/composites don't interfere with BuiltInResolver (and the same thing can be said about all of the resolvers we implement in Implement NpgsqlDataSource #4495) we can put BuiltInResolver first and enums/composites last (+ resolvers from Implement NpgsqlDataSource #4495).
3. While we do cache the results of the resolvers, there is an exception to that rule: resolving by value. Because of DateTime's kind we have to return either timestamp or timestamptz.

In light of the above I propose:

1. We do implement a single resolver for custom types.
2. We consider sorting resolvers (putting BuiltInResolver first, most of out internal resolvers after, and anything a user adds before BuiltInResolver).

What do you say?

We do implement a single resolver for custom types.

Though that's probably going to complicate things for the global type mapper...

@NinoFloris what do you think of the above? We've discussed simplying our type handler concepts by bringing ideas across from Slon; if we do that, it may not be worth worrying too much about the current situation...

Right, Slon's model also relies on resolvers for this work so in that respect nothing changes. If there are a huge number of (user) resolvers to check before ending up at the builtin set it would equally slow things down until the cache is properly filled.

I would probably have something like the following order:

• Builtin
• User mappings (just one resolver)
• (Additive) plugins (however many resolvers as there are plugins)

In Slon the only time you need another resolver to be first is for overriding the given converter for some clr type or overriding info (default clr type for a pg type, text writing preferred etc).