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

From: "Hans Buschmann" <buschmann(at)nidsa(dot)net>
To: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: "John R Pierce" <pierce(at)hogranch(dot)com>, <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #14192: pg_dump/pg_restore omit setting search_path in restored db
Date: 2016-06-16 07:39:35
Message-ID: D2B9F2A20670C84685EF7D183F2949E2373D62@gigant.nidsa.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs


I understand the differences between cluster and database and pg_dumpall and pg_dump.

In my opinion a pg_dump of a database should pack all informations of the application (the database) in the dumpfile in one container, to be able to restore it full functional at a different place.

Because the search_path is a crucial information for the application to work correctly (like any other object inside the database) it should be packed into this container called pg_dump dumpfile.

This should be independent of the current implementation, where we store the search_path in a cluster record: The informatation belongs semantically to the content of the database, even if it is stored elsewhere.

My concern with promoting this suggestion is to avoid trouble in emergency cases, logical consistency, intuitive usage of pg_dump and smooth experience for non-expert people.

Hans B.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message jeremy.rumerio 2016-06-16 08:52:01 BUG #14196: Processes terminated with exception 0xFFFFFFFF
Previous Message Michael Paquier 2016-06-16 07:28:45 Re: BUG #13907: Restore materialized view throw permission denied