I think this talk misses one of the most important security patterns of PostgreSQL and SQL-databases in general. If you for example have a table with hashed passwords. Why would any user except admin need to be able to make a select on that table? Make a function to validate the user and only grant permission to run this function.
That's a bad idea, because it implies that your password hash has to be expressible inside of Postgres.
If you're worried about a SQL dump exposing password hashes, segregate password validation into its own microservice. This comes with other benefits: for instance, you can ratchet up the work factor on your password hash, because the service will very easily scale horizontally.
First of all, this pattern is not exclusive to password hashes. There are lots of situation when handling customer data where you simply don't need the ability for the client to query the whole data-set, and if that's the case, allowing it is just bad hygiene.
Now if you make a good set of prepared statements as an interface for your database, this could be viewed as a "micro service" in it self.
