PostgreSQL puts the pedal to the metal with some smart indexing tweaks in version 12

PostgresSQL is good. It should say in large letter on the front somewhere that it does procedural overloading. I was working with it in a group and I like to write procedures to help keep things tidy and separate and no-one told me it did overloading. Wierded me out for a few days - especially as the experienced workers there didnt seem to know.

I'm struggling to think of features that SQL Server has that Postgres doesn't come with or have extensions for. Maybe management functions? In other areas Postgres seems to be leading the pack.

For really high-end deployments, EnterpriseDB's version comes with support for Oracle's backend which makes migration of some large installs feasible.

With a slightly better toolset and some more goodies it would be an adequate replacement for SQL server.

Would you be so kind as to list any toolsets/goodies you would like to see in PostgreSql ?

A couple of things? SQL Server is more advanced in every aspect and has hundreds of features that Postgresql doesn't. Not to mention that SQL Server is many times faster than Postgresql in typical use.

Postgresql is OK only for something where you don't need an enterprise grade solution and support. You get what you pay for.

The text search engine is awesome.

Re: Can you configure a database as case insensitive now???

Definitely not the default. Perhaps you can not imagine a scenario where performance matters, but I think that's the more common case and the defaults should always back the most common case. The solution to your problem is to standardise your data once before you store it, rather than to waste time on every single subsequent search. The data in your columns should be homogeneous, the most common case problems come in for things like Names, which is a handful of text columns across the whole database - if it's not then perhaps a graph/noSQL DB would better suit the use case. If one is searching for free text typed into a field like 'Notes' then I would say some better categorisation columns are required. Notes should only be relevant once you are looking at a record - not be used to find a record - if desperate then sure, go ahead and search on it - but let's not change the defaults to fit the one desperate use case of a poorly designed system. (To be clear, I am not saying your system is poorly designed, just my example 'Notes' use case system)

Re: Can you configure a database as case insensitive now???

Searching and sorting are not the same so I'm not quite sure what the issue. In general, for columns you should normalise your data for whatever processing you're going to do. Case-sensitive sorts are almost always going to be fastest and you can define pro-table or pro-column collations and you can even do this pro query. See the docs for more information. The docs aren't perfect but that was the first page that popped up when I searched for collation, though as long as you don't use the LOCALE_C you shouldn't have too much trouble.

For searching, there are worlds of difference between using the builtin LIKE or REGEX and the text search extensions. If you do have data that is case sensitive but want to do case insensitive search (you have "JOBS", "jobs" and "job" in your data), then you really should normalise your data and/or query, or at least use a relevant index.

For full-text searches case sensitivity is the least of your worries!