Prev: Vacuuming leaked temp tables (once again)
Next: gsoc, text search selectivity and dllist enhancments
From: Richard Huxton on 27 Jun 2008 12:51
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.

tracker=> SELECT name,setting,source FROM pg_settings WHERE name =
'DateStyle';
name | setting | source
-----------+----------+----------
DateStyle | SQL, DMY | database
(1 row)

pg_dumpall -U postgres -p 5483 -g > tracker.global.schema
pg_dump -U postgres -p 5483 --schema-only > tracker.schema
grep -i datestyle tracker*schema
<nothing>

That's with 8.3.3

Am I doing something stupid here?

--
Richard Huxton
Archonet Ltd

--
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: Richard Huxton on 27 Jun 2008 12:58
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?

--
Richard Huxton
Archonet Ltd

--
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: Tom Lane on 29 Jun 2008 23:44
Alvaro Herrera <alvherre(a)commandprompt.com> writes:
> Robert Treat wrote:
>> 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.

So put forward a worked-out proposal for some other behavior.

My first thought is that the -c and -C options create a lot of the
issues in this area. -c in particular is evidently meant for merging a
dump into a database that already contains unrelated objects. (In fact
you could argue that the *default* behavior is meant for this, -c just
changes the result for conflicts.) It seems unlikely that having
pg_dump issue ALTER DATABASE SET commands is a good idea in all of these
scenarios.

I'm also wondering why it'd be bright to treat ALTER ... SET properties
different from, say, database owner and encoding properties.

regards, tom lane

--
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: Richard Huxton on 30 Jun 2008 04:38
Tom Lane wrote:
>
> So put forward a worked-out proposal for some other behavior.

OK

> My first thought is that the -c and -C options create a lot of the
> issues in this area. -c in particular is evidently meant for merging a
> dump into a database that already contains unrelated objects. (In fact
> you could argue that the *default* behavior is meant for this, -c just
> changes the result for conflicts.) It seems unlikely that having
> pg_dump issue ALTER DATABASE SET commands is a good idea in all of these
> scenarios.

Can't comment on --clean since I don't use it. I've always assumed it's
for the case where you don't have a user with permissions to
drop/recreate a database (e.g. web hosting).

IMHO the time a dump/restore should be issuing ALTER...SET on a database
is when it has issued the corresponding CREATE DATABASE. If you want to
tweak this sort of thing, just manually create the database with
whatever options you want and don't use --create.

> I'm also wondering why it'd be bright to treat ALTER ... SET properties
> different from, say, database owner and encoding properties.

Not sure what you mean here.

--
Richard Huxton
Archonet Ltd

--
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: Tom Lane on 30 Jun 2008 19:45
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.

This would mean duplicating some functionality between pg_dump and
pg_dumpall ... or maybe we could move all that logic over to pg_dump and
have pg_dumpall use --create when invoking pg_dump.

regards, tom lane

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

 |  Next  |  Last
Pages: 1 2
Prev: Vacuuming leaked temp tables (once again)
Next: gsoc, text search selectivity and dllist enhancments