Consider redoing extensions, enums, ranges via ModelDiffer

Our current support of PostgreSQL-specific database objects (extensions, enums, ranges, soon hopefully composites) is currently done purely via annotations - objects are represented as metadata on the model, which are then flowed into migrations via annotations on AlterDatabaseOperation. This is unlike EF Core’s support for sequences, for example, which has metadata annotations (like us) but then picks up the sequences in the ModelDiffer, which then generates special {Create,Drop,Rename}SequenceOperation.

Our approach is problematic for the following reasons:

• Addition/removal of objects needs to be done in our MigrationsSqlGenerator - compare old and new annotations on an AlterDatabaseOperation, calculate what was added, what was removed, etc. This work conceptually belongs in ModelDiffer rather than in MigrationsSqlGenerator.
• It’s impossible to implement correct DefaultSchema support, because we have no way of knowing that the DefaultSchema has changed, and that our database objects need to be moved accordingly (see https://github.com/npgsql/Npgsql.EntityFrameworkCore.PostgreSQL/pull/685#issuecomment-443488785).

In the past, we already have a discussion about providing our own ModelDiffer, which would generate custom migration operations (e.g. CreateEnumOperation). This would be a better design and align us with the way EF Core does things. It may be worth revisiting for 3.0 in case we change our minds.

/cc @austindrenski @ajcvickers @divega @bricelam

[bricelam]

Oh, and I’m certainly not pushing back on having Npgsql override it (the changes we made in EF Core 2.0 make it safe to do). It’s just something that providers shouldn’t ever have to override so when they do, it’s a good sign we’re missing extensiblity points elsewhere.

[roji]

OK. I’d recommend not going too far into this without showing an approach we can discuss, to make sure we all agree on where we’re going etc.