Andreas Pflug wrote: > Alvaro Herrera wrote: > > > > Is anybody working or considering to work on pg_upgrade, or is all this > > hypothetical? Our past history has seen lots of people offering to work > > on pg_upgrade, and none has produced a working version. Is it fair or > > useful to impose restrictions on development just because it's remotely > > possible that somebody is going to be motivated enough to consider > > producing it? > > Depends on the impact the restriction imposes. If > stability/scalability/functionality or so is affected, this sounds not > tolerable. If it's about not saving two bytes that have been spoiled for > ages before, or keeping a backward compatibility type, it appears > feasible to me. > Changing on-disk structures at the start of the 8.2 dev cycle is a > guarantee that nobody will implement pg_upgrade for 8.2.
Let's go ahead and apply the patch. While this change isn't very significant, I bet there will be other changes in 8.2 where we will want to change the database for a significant benefit, like reducing the tuple header by 4 bytes by recompressing the four xid/cid fields back into three. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
