Will be great to have a dry run option, because the time to verify reduces a lot and will save space on disk, because just execute with no write to disk.
"Dry run", the way I understand it, can be accomplished via the "-l" (ell) switch. It means - "tell me what is going to happen but don't actually do it". I don't know what to call what you are describing but I don't see how it could reasonably be made to work and give the admin confidence that a true restoration would be valid. Maybe I'm just being unimaginative but at minimum you'd have to write out the tables to disk so data could be loaded into them. Then data would have to be persisted in order to validate the constraints at the end.
If you are running out of disk space you should get larger/more disks.
Personally, I'd probably setup a dedicated "test restore" cluster with lots of HD and put stuff like "fsync=off" into its postgresql.conf.
I could see having a "--make-tables-unlogged" option that would convert, on-the-fly, all CREATE TABLE commands to "CREATE UNLOGGED TABLE" commands.
