I'm not quite seeing the sense of insecurity here, especially from the conclusion. Like any piece of software, it's up the user to not use "dangerous" configurations.
Also, isn't Docker people the ones talking about unikernels? Where everything run not only with superuser powers, but at kernel level?
So, "by default, quite secure; except this one default that exposes you to some very nasty attacks unless you override it".
Was there some specific aspect or attack vector that came to mind? Or did you mean it more as a blanket warning?
That's all for the cases where the same query plan is used in 9.0 and 9.5 - the differences where new type of plans (say index only scans) are often very large.
In short: yes.
Now that 9.5 has its own branch I hope we'll get it in early in the 9.6 development cycle; so we have time to iron out all the potential kinks.
I don't think there ever was a clear "this will be in 9.5" statement from anyone?
Please add more extension (like: postgis,hstore)
The use case not highlighted by the blog post is is disposable databases for use with automated tests. One of my inspirations was the idea of using a Vagrant VM as a development environment and deleting each night and re-creating it each morning so that the project doesn't accumulate untracked dependencies on environment tweaks. I'd like to enable/encourage similar practices for DBs. For that, I'm working on a Jenkins plugin.
