Update enum quoting and default schema use

[austindrenski]

Changes

• If no schema is specified in .ForNpgsqlHasEnum(...), then use the default schema annotation.
• Properly quote schema-qualified enums for literal generation and mapping (override StoreType).
• Cache mappings from CLR values to PostgreSQL labels.

Fixes: #554
Fixes: #593

[YohDeadfall]

Does this request fix #623? If not, please fix it in a different PR, not here. This would make it easier to track changes.

[austindrenski]

@YohDeadfall I mistakenly thought there would be some overlap in the issues, but they are indeed distinct. None of the changes included here are intended to address #623 (other than improving enum support, generally).

[YohDeadfall]

Otherwise looks good.

[austindrenski]

Updated to Npgsql 4.1.0-ci.1270 to use the default name translator from npgsql/npgsql#2137.

[austindrenski]

Rebased and updated to reflect #621.

[roji]

@austindrenski I'll give this a full review, but can you please make clearer exactly what this PR covers? Is the description above still valid or has the scope of this PR changed?

Regardless, one thing that immediately caught my eye:

Default schemas will affect downstream created types that do not specify schemas.

This doesn't seem like the correct EF Core behavior. Executing the following:

builder.Entity().ToTable("blogs");
builder.HasDefaultSchema("my_schema");
builder.Entity().ToTable("blogs2");

Results in two tables being created under my_schema. As a general rule, everything that happens in OnModelCreating() configures the model and has no order whatsoever; the default schema is a property on the model that simply gets set. Then, we the database is actually created, the model is translated to migrations, but the original order in OnModelCreating() has already been lost.

[roji]

BTW does this depend on npgsql/npgsql#2121, whose PR npgsql/npgsql#2123 still seems to be WIP?

[austindrenski]

can you please make clearer exactly what this PR covers?

Sure, I'll clean that up today. This PR grew and shifted a bit since I opened it, so the current description is a bit of lazy editing on my part.

This doesn't seem like the correct EF Core behavior.

Early on for EF Core, I thought I read some docs that discussed order being relevant in configuration, but I can't seem to find anything like that now. (Could have been a third-party blog, TBH.)

What you describe makes more sense (and matches the internals too). I can go back through and move the default schema detection later in the process.

BTW does this depend npgsql/npgsql#2121

No, not anymore. An earlier draft was, but I reworked this one to use the simple "split on the first dot" approach while I work through npgsql/npgsql#2121 (which has turned out to be a bit more confusing than I first imagined).

[austindrenski]

@roji The description is up to date, and I've rebased for the current dev. I've also rebased #626 which follows this PR with similar fixes for user-defined ranges.

I'd like to see this make it into v2.2.0, any chance you can give it a review before the next preview release?

@YohDeadfall Could you also give this another review?

[austindrenski]

@YohDeadfall Appreciate the review—updated.

[austindrenski]

I'd like to merge this and #626 tomorrow at 1:00 PM (UTC).

If anyone wants more time for another round of review, just let me know.

/cc @roji@YohDeadfall