The syntax from the command line is much more difficult in psql starting out----but it's easy to get used to. Personally, I've used both MySQL and Postgres gui tools (almost all of them) and I always end up going back to the command shell. That's how I learned em both, and they're my favorite. phpmyadmin and the same tool for postgres work well though through a web interface.
As far as comparing MySQL to a true RDBMS, in the real world there is NO comparison. MySQL doesn't enforce the Atomicity of transactions, nor does it support row level locking ( a default setting in MsSQL and Oracle), nor does it support SPs or Triggers.
Mysql also has a 4GB DB Size limitation and Postgres has a 64 GB limitation as of the last versions I used.
If you're using Mysql or Postgres in a multi-user environment where multiple reads/writes can be committed to the database----you'll have to write your own mechanism for locking records to avoid writing collisions.
Pre Mysql 4.0 the biggest difference between Mysql and Postgres was the lack of support for foreign keys in Mysql. While you can still use Lookup records in much the same way---mysql doesn't enforce an once of a DB Model on the DB Side. If you have a "related" table in MYSQL there's nothing preventing you from inserting a dubious record in your lookup field other then your own code.
Postgres does do the job of handling foreign keys fairly well, and it does allow for user defined functions. However----on larger databases---like the last project I worked on with it we had a 15 GB db, the performance differential is very noticeable. I've lost my timing chart that I created for Posgres vs MSSql on that project---but in some cases with multiple inserts and deletes with cascading constraints----Postgres was 300% to 400% slower. [edit] ON massive updates with multiple join queries to the reporting tables (all dynaically created on each call of a report) postgres was sometimes 2000% - 3000% slower. Granted---that was an unfair test for postgres as the entire process involved a table delete by key, multiple query build to temp recordset, followed by a massive row by row insert. I could have really kicked postrgres's arse w/ MSSql if I had moved that code to all Sp's and triggers---but I just tested it from a web client keeping all the recordsets local to the web server. It was also an unfair test in the way that the reports worked too---they weren't being pulled from SPs...but on large reports, the Crystal Engine had to pull all of the results for each report, and then pull each subreport results as well----and the crystal pull is multi-threaded....so even the rendering favored MSSQL in that case.......
But---all in all----there are clear cases where Mysql is a good alternative. And cases as well where Postgres fits the bill. THe company I was at was a non-profit company, and they saved a buttload using Postgres instead of a true RDBMS----but a year after I left they convert4ed to oracle b/c the database size & the performance drop-down was too much for the 40 or so users to deal with.
--------------------------------------------------------------------------------