Re: Proposal for restoring a dump into a database with a different owner
От | Bruce Momjian |
---|---|
Тема | Re: Proposal for restoring a dump into a database with a different owner |
Дата | |
Msg-id | 200806301950.m5UJo6p03894@momjian.us обсуждение исходный текст |
Ответ на | Proposal for restoring a dump into a database with a different owner (postgresql.20.j_random_hacker@spamgourmet.com) |
Ответы |
Re: Proposal for restoring a dump into a database with a different owner
("Scott Marlowe" <scott.marlowe@gmail.com>)
Re: Proposal for restoring a dump into a database with a different owner (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-admin |
I see you didn't get a response this request. I am thinking it would be better to implement some form of massive change ownership option that can be done to change ownership after the dump is restored. --------------------------------------------------------------------------- postgresql.20.j_random_hacker@spamgourmet.com wrote: > Hi, > > I have the same problem as Andreas Haumer did in this thread: > http://archives.postgresql.org/pgsql-admin/2008-01/msg00128.php -- I want to > be able to easily (i.e. programmatically) copy a database from one place to > another, changing the owners of all contained objects in the process. > > While I very much appreciate Tom Lane's fast and helpful responses to > Andreas on that thread, it doesn't quite address my problem: there is no > simple, automatable 1- or 2-step process that can accomplish this (without > Andreas's (admittedly neat) trick of temporarily changing the destination > user to superuser status). The best I've been able to do is hack up a Perl > script that parses the output of pg_restore -l, directing > superuser-requiring operations to one file and non-superuser-requiring > operations to another; but afterwards the superuser-requiring operations > still have to have the owners of the objects they produce manually > reassigned. > > My instincts (which could be wrong...) tell me that this is actually a > fairly common problem. So, I suggest the following enhancement to > pg_restore: add a --map-users command-line option that accepts the name of a > file containing two usernames on each line, <from> and <to>. Then (provided > -O was not specified) when producing ALTER ... OWNER TO commands, simply > replace every <from> user listed in this file with the corresponding <to> > user. > > Another niggle is that the COMMENT ON DATABASE command, produced by > pg_restore when run without the -d option, always refers to the name of the > original database, which will cause an error if the new DB has a different > name. It would be nice to have an option (or other means) to remedy this. > > It seems to me that these things would be pretty simple to implement and > sufficiently general to tackle this problem neatly, without opening up any > security holes (you would still need to be *some* DB superuser for the ALTER > ... OWNER TO commands to work). > > Does this sound sensible? If Tom or another high-ranking PostgreSQLer okays > it in principle, I suppose I could try developing a patch for pg_restore > myself. (Never done this before but there's a first time for everything...) > > TIA, > Tim White > > > > -- > Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-admin -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-admin по дате отправления:
Предыдущее
От: "Domingo Alvarez Duarte"Дата:
Сообщение: Re: Extended security/restriction to any role with login access
Следующее
От: "Scott Marlowe"Дата:
Сообщение: Re: Proposal for restoring a dump into a database with a different owner