Re: -Wformat-zero-length

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@2ndquadrant.com>, Peter Eisentraut <peter_e@gmx.net>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2012-08-09T13:20:23Z
Lists: 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