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

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Hans Buschmann <buschmann(at)nidsa(dot)net>
Cc: John R Pierce <pierce(at)hogranch(dot)com>, "pgsql-bugs(at)postgresql(dot)org" <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 11:43:00
Message-ID: CAKFQuwZu=Wuap2Od6zi4jmafNb+UrV+unQfB+n+yw3biBYcC_g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thursday, June 16, 2016, Hans Buschmann <buschmann(at)nidsa(dot)net> wrote:
>
> 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.
>
>
You've made your opinion quite clear and likely others share it. But
someone needs to design and write a patch - we can't commit opinions. I'd
suggest, at least pushing for this after 9.6 is released. No one is really
interested in pondering this days before beta2 is to be released. I'd
suggest researching past discussions on the topic, I'm sure there are some,
in the meantime.

David J.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message sheri.bhavani 2016-06-16 12:22:49 BUG #14197: ERROR: character with byte sequence 0x81 in encoding "WIN1252" has no equivalent in encoding "UTF8"
Previous Message jeremy.rumerio 2016-06-16 08:52:01 BUG #14196: Processes terminated with exception 0xFFFFFFFF