Feature - Use enum to pick index method

It would be nice to have an overload of

.ForNpgsqlHasMethod("gin");

that accepts an enum value. Primarily for intellisensability. (I would do this, if approved)

[roji]

There are already various other places where PostgreSQL lists of values are specified as strings - notably types (e.g. when users specify HasStoreType()). We can start wrapping all of these with enums and similar, but the value seems rather limited and we’d have to update these as PostgreSQL adds new ones…

In general it seems preferable for users to consult the PostgreSQL documentation to know these values - at the very least we should point them towards the right page from the xmldocs.

[roji]

@austindrenski thanks for the good responses above, here’s some more from me.

First of all, I have to start by saying I appreciate the work you’ve done so far. This provider is better than most out there.

Thanks for saying that! That’s also good to hear.

On the issue of index method enums, it’s worth saying I’m not totally against the idea. However:

• I do think a good API has to be consistent, and it’s not ideal to have an enum for index methods but not for other settings - which is why I approach this question from a more global standpoint. Adding just an index method enum would leave users somewhat confused IMO.
• The actually value seems rather low. Yes, it’s always better to catch typos in compile-time rather than run-time, but since index methods are part of migrations a typo would be discovered very quickly (and in a risk-free way, as migrations run in transactions). It isn’t some obscure runtime branch that would fail at some random late point.
• Index methods are a very rarely-used and advanced feature, so once again people can be expected to discover the methods themselves and ensure they have no typo.

On the specific questions, to supplement @austindrenski’s responses:

Is the check constraint implemented?

Blocked upstream, tracking via #837.

This has actually been unblocked at the EF Core side, I’m not actually sure we need to do anything to make it work in Npgsql (but obviously testing is needed).

If I use .ForNpgsqlUseSequenceHiLo(), How would I specify a sequence start value?

The HiLo feature seems to be very rarely used (not just with PostgreSQL, but in general in EF Core), and this is the first time anyone has raised the lack of support for specifying the starting value. See my comment at the bottom about eagerly implementing features without a clear need, but if you’d like you can open an issue for this.

If I use .UseNpgsqlIdentityColumn() How would I specify identity start, current, increment and min max values?

This is tracked by #819 and will hopefully make it into 3.0.0.

How do you ensure that the raw SQL you have to write to make the above work gets applied to a test database created using EnsureCreated() ? Do you Migrate() your test databases?

I’m not sure I understand the question - is this a general EF Core question on how EnsureCreated() interacts with migrations? It doesn’t seem to be specific to the Npgsql provider.

If any of the above works, can we specify them in the docs

Our docs are a always a work in progress that could certainly use more attention. PRs are always welcome 😃

Very much agree - our docs could definitely use some work. It’s not always easy to keep them in sync with actual features, and it’s possibly a good place for contributors to start as they’re exploring/discovering the provider.

What is holding this project back from being feature complete? Is it the upstream project? is it lack of time/contributors?

Feature completeness is always going to be a high bar when considering a backend as feature-rich as PostgreSQL. More contributors would certainly help, and new contributors are always welcome!

Agree as well - the range of features is potentially extremely large, and you can see the same issue in Microsoft-developed providers as well (e.g. SQL Server / Sqlite). In some cases we are also limited by upstream EF Core, but in general this is an open source project maintained by the community.

As a general rule, I personally try to avoid rushing into feature implementation without users asking for them, or without a plausible reason to believe it would be useful. In this project it’s very easy to fall into the trap of eagerly implementing tons of features and translations with the goal of being feature-complete (and because it’s fun/interesting), but which almost nobody will use, and which we then have to maintain. So while it may sound odd, I’d say feature-completeness isn’t exactly an explicit goal.

If you see anything you’re interested in it would definitely be great to have you (and anyone else) as a contributor!