[allan_s]

yes I understand I can do that, and I also understand why the authors chose to do that, I would have done the same.

My point of view is more from a small saas company perspective (i.e 100% pragmatic):

1. I want as less vendor as possible, especially on something as mission critical as my database 2. I already use AWS RDS and it comes with a LOT of nice things (managed, multi-az, easy backup/restore story, etc.)

In that situation:

1. hosting myself is not an option because I will loose all the niceties that I will have to reimplement 2. buying from a 3rd party is not an option either because: 1. What if they go bankrupt ? 2. We are ISO 27001 and they may be not ISO 27001 themselves or forever. 3. If I choose a vendor because it's "postgres + feature A" then if there's an other vendor selling "postgres + feature B" (timescaledb etc.) what do I do ?

That's why I was more interested in knowing if that specific could one day be implemented in postgres directly (as there's already tsvector).

Once again I'm 100% behind them to have chosen a restrictive license if they plan on selling it, but in that case their interested and mine are not aligned, and that's fine.

[j45]

That's a really fair use case acknlowedging personal preference to interpret how you like it.

I find some of the built in services on clouds are just open source libraries that are packaged up to increase tie in to that platform.

I like cloud, but cloud agnostically, and hybrid/private clouds in the mix with that seem like a good skill to at least be able to consider thinking through.