databases.rake: db:dump task abuses "schema_search_path" and makes false assumptions about `pg_dump --schema`

The db:rake task as defined in databases.rake is problematic on PostgreSQL databases:

• It misinterprets the schema_search_path option defined in config/database.yml as an authoritative, complete list of schemas relevant to the application. It uses it to construct a list of --schema= options to pg_dump to dump only the schemas listed there.
• It mistakenly assumes that "pg_dump --schema=foo,bar" will create a self-sufficient dump of the "foo" and "bar" schemas. This is not the case. pg_dump(1) explicitly points out that non-schema objects will not be dumped if --schema=... is specified, because they do not belong to any given schema.

This has the following real world consequence:

If an explicit schema_search_path is specified in config/database.yml, and the database has a procedural language — a non-schema object! — installed (e.g., plpgsql) that is not also installed in the template1 database, and any functions defined in any of the schemas specified in schema_search_path use that procedural language, then the dump created will not be self-sufficient and restoring the dump, e.g., during running of unit tests, will blatantly fail.

Note that there are other real-world cases where "pg_dump --schema=foo,bar" will fail to create self-sufficient dumps, e.g., when a table in schema foo has a column default or a constraint referencing a function in schema quux, or when it has a foreign key to a table in schema quux. And there are very legitimate reasons for not simply including all of a database's schemas in schema_search_path. It is a search path, not an authoritative, complete list of schemas being used by the application, after all!

I think a proper fix would be to never use the --schema= option in the db:dump task's invocation of pg_dump, thereby not limiting the dump to only a specific (or rather arbitrary) set of schemas. Since no data is being dumped this should not be prohibitive.