Re: Fixing pg_dump

Поиск
Список
Период
Сортировка
От Christopher Kings-Lynne
Тема Re: Fixing pg_dump
Дата
Msg-id 40DE83AD.2060207@familyhealth.com.au
обсуждение исходный текст
Ответ на Re: Fixing pg_dump  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Fixing pg_dump  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
>>But...it seems kind of hacky to scan it again for owners and privs - are 
>>you sure you want me to go that way?
> 
> If there's not a big performance penalty, sure.  Being fully compatible
> with existing archive files is a sufficient win to justify sins much
> worse than this one.

Ah, crap.

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.

For example, consider an operator. It's not enough for me to know the 
name of the operator, I also must know the type of its operands.

That given, I see no way to implement this using a second scan, except 
perhaps rewriting the drop command...which is extremely dodgy!

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!

Chris



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: xeon processors
Следующее
От: Shachar Shemesh
Дата:
Сообщение: Custom type with width specifier