Prev: TODO item: Allow data to be pulled directly from indexes
Next: A new take on the foot-gun meme
From: Robert Treat on 29 Jun 2008 22:47
On Friday 27 June 2008 12:58:41 Richard Huxton wrote:
> Richard Huxton wrote:
> > Richard Huxton wrote:
> >> At present it means you can't reliably do:
> >> DROP DATABASE foo;
> >> pg_restore --create foo.dump
> >> I'd then have to either hand edit the dumpall dump or wade through a
> >> bunch of errors checking that none of them were relevant.
> >
> > Actually, I'm not sure pg_dumpall does them either.
>
> [snip]
>
> > Am I doing something stupid here?
>
> OK - so to get the ALTER DATABASE commands I need to dump the schema for
> the entire cluster. Is that really desired behaviour?
>

Certainly not desired by a number of people I have talked to, but I don't have
much hope in seeing the behavoir change... perhaps someday if we get around
to merging pg_dump and pg_dumpall....

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Alvaro Herrera on 29 Jun 2008 23:30
Robert Treat wrote:
> On Friday 27 June 2008 12:58:41 Richard Huxton wrote:

> > > Am I doing something stupid here?
> >
> > OK - so to get the ALTER DATABASE commands I need to dump the schema for
> > the entire cluster. Is that really desired behaviour?
>
> Certainly not desired by a number of people I have talked to, but I don't have
> much hope in seeing the behavoir change... perhaps someday if we get around
> to merging pg_dump and pg_dumpall....

I have never heard anyone say the current behavior is something they desired.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Treat on 1 Jul 2008 08:51
On Tuesday 01 July 2008 03:45:44 Richard Huxton wrote:
> Tom Lane wrote:
> > Richard Huxton <dev(a)archonet.com> writes:
> >> Tom Lane wrote:
> >>> So put forward a worked-out proposal for some other behavior.
> >>
> >> IMHO the time a dump/restore should be issuing ALTER...SET on a database
> >> is when it has issued the corresponding CREATE DATABASE.
> >
> > So pg_dump would produce this info when, and only when, you'd used
> > --create? I agree that it seems sensible in that case, I'm just
> > wondering if that will cover all the use-cases.
>
> Well, in the -Fc case you'd produce it always and pg_restore would only
> emit it when you --create.
>
> The only time we need to restore per-database settings is if the
> database has been dropped. If you're not having the dump/restore
> re-create the database then presumably you've taken charge of the
> per-database settings.
>

I'm not sure I agree with that entirely. For example, one common usage
scenario when upgrading between major versions is to create the database,
load contrib modules (whose C functions or similar may have changed), and
then load the dump into the database. In those case you still might want the
database settings to be dumped, even though you are creating the database
manually. (Now, one might argue that you could still dump with --create and
ignore the error of the database creation command, but that probably isn't
ideal).

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 | 
Pages: 1
Prev: TODO item: Allow data to be pulled directly from indexes
Next: A new take on the foot-gun meme