How sensitive is the data? You didn't say. That makes it impossible to gauge what's an appropriate level of risk. That's crucial. "Secure enough" is always relative to the risk, and your budget for the project.
This sounds like one of those "prove something doesn't exist" situations. Logically, that's impossible to do. You can only prove when something does exist. So I'm not going to succeed. But regardless, I'll give a shot at convincing you that for typical data, "secure direct access to databases for untrusted users" does not really exist.
The connection is only part of the "secure access" problem. Let's assume you've dealt with all of the possible negotiation downgrade exploits and so on. Even if the connection is encrypted with a bug-free TLS crypto suite that's properly configured, what data are the untrusted users sending through or before the encrypted channel, including (as Craig Ringer mentioned) authentication? Are you sanitizing it before it reaches the database?
Patching is obviously required, but not remotely enough. For a database that could have people exploiting it at any time, including other users' data in the database, you'd probably want DAM (database auditing and monitoring) and application-aware IPS and DoS protection. There's a reason that best practice is to put the database behind a gateway of some kind, and not directly expose it like that.
Running on a non-default port is security through obfuscation. It won't stop anyone that knows how to run a port scanner and fingerprinting, and definitely not anyone that is targeting you. Since you don't trust your users, you probably should assume one is targeting you.
IP range limitations won't help either if you don't trust any user IPs. Trusted hosts are useful only for allowing trusted IPs, and blocking the rest... which in your case sounds like blocking every IP on the Internet. Not very useful.
Assuming you've dealt with all of that, what I would suggest is transactions, backups, and strongly encrypting each user's data inside the database with their own private keys that your server doesn't have access to, so that even if a malicious user compromised the database, a dump of other users' data would be basically useless to the attacker. Have a standby server VM ready to go at all times, and it wouldn't hurt to have detached storage so that you can periodically trash that VM and bring up a fresh one. That wouldn't prevent someone from owning the server, but would at least help to protect the data itself, and offer rapid incident response and recovery.
But that's before you even get into the details specific to PostgreSQL.
As you can see, stronger security gets expensive and time-consuming. If the data is cat doodles on napkins, it's probably not worth it. You'd be better served by a different access method.