Re: Fixing pg_dump
От | Tom Lane |
---|---|
Тема | Re: Fixing pg_dump |
Дата | |
Msg-id | 11914.1088347366@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Fixing pg_dump (Christopher Kings-Lynne <chriskl@familyhealth.com.au>) |
Ответы |
Re: Fixing pg_dump
|
Список | pgsql-hackers |
Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes: > I tried adding the extra scan in and it as all well and good up until > the second where I realised that the TocEntry struct has no field that > allows me to know the correct way of finding the full descriptor of each > object. Ugh. Definitely an oversight. Don't suppose you want to think about pulling the name out of the DROP command ;-) ? > I'm running out of time unfortunately, and I need to know from you > whether I should go back to my work on making owner and acl TOC entries > fully independent? All this means is that people restoring pre-7.5 > binary dumps into 7.5 will not get the owner fixes... But people using > the binary format to upgrade seems like a pretty rare case to me! Hardly --- for instance, people using large objects have no other choice. You can *not* change pg_restore in a way that will make it impossible for such people to restore their dumps (and no, I don't think it will fly to tell someone after the fact they should have used 7.5 pg_dump...) Maybe it's sufficient to have a backwards-compatibility mode in which the SET SESSION AUTH commands still get issued same-as-ever. In fact, you could just automatically do that if you see the archive version is too old to have ALTER OWNER support. On the whole though, I think editing the DROP commands might be the best way. Are there any cases where that would actually not work? regards, tom lane
В списке pgsql-hackers по дате отправления: