Re: -Wformat-zero-length
От | Robert Haas |
---|---|
Тема | Re: -Wformat-zero-length |
Дата | |
Msg-id | CA+TgmoYwS1e39khowehzgv8P4f+DKARWabP8C4FfSeF9hkV7MA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: -Wformat-zero-length (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: -Wformat-zero-length
|
Список | pgsql-hackers |
On Wed, Aug 8, 2012 at 7:04 PM, Bruce Momjian <bruce@momjian.us> wrote: >> The point I think Robert was trying to make is that we need to cut down >> not only the complexity of running pg_upgrade, but the number of failure >> modes. At least that's how I'd define improvement here. > > Agreed. Even with these changes, I still see a lot of complexity. I agree. That's why I said it needs some serious engineering time to file down the rough edges, plural, not that it needs this fix in particular. This would help to make things less error-prone, but it's far from the only thing that is needed. As to what exactly is needed, well that's up for discussion. One of the big failure modes for pg_upgrade is... pg_dump's dump fails to restore. That bothers me quite a bit because there are actually a lot more people who rely on pg_dump than there are people who rely on pg_upgrade, and it turns out there are all of these edge cases that pg_dump doesn't actually handle all that well. Sure, you can edit the dump by hand (if you're not using pg_upgrade) but that sucks. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: