First of all, a database connection is faster then a file for random access or sequential access on a heavilly fragmented drive.
Yes. But why would you want to use something as powerful as Postgres just as a storage method? For it to be worthwhile you'd need to be doing a lot of random accesses during the course of the game and a heavyweight database just isn't practical for that sort of thing. A database query that takes 0.01 seconds to complete is fine for business, but that's a whole frame of your game gone in just one query.
If you need a lightweight databases for non-realtime file access and the occasional query then SQLite is pretty good because you can embed it into your program. For complex relational data tables with many queries (e.g. if your game uses a lot of stats) then a RAM-based DB like FastDB might be better than not using a database at all. YMMV.
That would not be a better method by a long shot! Parsing php output is much, much slower than traversing a resultset - particularly if we're talking about large ammounts of information.
Not faster, but a web service would be easier, more flexible, more scalable and wouldn't require the end user to install and administer the monster that is Postgres. And there's always the option I mentioned of connecting to a remote database directly.
I love Postgres by the way, but it's really not suitable for games in the same way that Blitz isn't designed for non-games programming.