BUG #14192: pg_dump/pg_restore omit setting search_path in restored db

The following bug has been logged on the website:

Bug reference: 14192
Logged by: Hans Buschmann
Email address: buschmann(at)nidsa(dot)net
PostgreSQL version: 9.5.3
Operating system: Windows 10 64bit
Description:

To transport a whole database from Production to test/development I dump the
whole database with pg_dump -d xxxdb -Fc -f mydumpfile.dmp.

After creating the database on the target system with createdb I restore the
database with pg_restore -d xxxdb mydumpfile.dmp. (no other flags except
login information involved)

All Information is correctly restored (2 schemas and their content) except
the search path.

On the origin database I had entered
ALTER DATABASE xxxdb SET search_path TO public,partition2;
The restore omits setting the search path, it must be entered again with
ALTER DATABASE on the target machine.

The same occurs naturally also in the case of an emergency restore in case
of failure, which breaks the restore from running correctly without
expertise of the underlying database in time of restoration.

With my understanding, that the search path is an inherent part of the
origin database structure, the pg_dump/pg_restore sequence does not
completely reproduce the original database. I think this is a bug.

All is done on 9.5.3, 64bit Windows edition on Windows 64bit platforms, but
I suppose it is platform independent. I haven't tested it on different
versions or platforms.

I haven't tested whether pg_dump or pg_restore omits the setting (mostly
because of not using an SQL dump format).

Thanks for looking