Re: Does anything dump per-database config settings? (was Re: ALTER DATABASE vs pg_dump)

Поиск
Список
Период
Сортировка
От Richard Huxton
Тема Re: Does anything dump per-database config settings? (was Re: ALTER DATABASE vs pg_dump)
Дата
Msg-id 48689B70.9040307@archonet.com
обсуждение исходный текст
Ответ на Re: Does anything dump per-database config settings? (was Re: ALTER DATABASE vs pg_dump)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Does anything dump per-database config settings? (was Re: ALTER DATABASE vs pg_dump)
Список pgsql-hackers
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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Heikki Linnakangas"
Дата:
Сообщение: Re: TODO item: Allow data to be pulled directly from indexes
Следующее
От: Jamie Deppeler
Дата:
Сообщение: Postgresql 8.3 issue