On Wednesday 11 September 2002 05:40 pm, Oliver Elphick wrote:
> On Wed, 2002-09-11 at 21:19, Tom Lane wrote:
> > In the meantime, I think that we shouldn't mess with pg_dump's basically
> > OID-order-driven dump ordering. It works in normal cases, and adding
> > arbitrary rules to it to fix one corner case is likely to accomplish
> > little except breaking other corner cases.
> I can see that Lamar and I are going to have major problems dealing with
> users who fall over these problems.
Yes, we are. Thankfully, with RPM dependencies I can prevent blind upgrades.
But that doe not help the data migration issue this release is going to be.
Guys, migration that is this shabby is, well, shabby. This _has_ to be fixed
where a dump of 7.2.2 data (not 7.2.0, Tom) can be cleanly restored into 7.3.
That is, after all, our only migration path.
I think this upgrade/migration nightmare scenario warrants upping the version
to 8.0 to draw attention to the potential problems.
> It seems to me that I shall have to make the new package such that it
> can exist alongside the old one for a time, or else possibly separate
> 7.3 pg_dump and pg_dumpall into a separate package. It is going to be a
> total pain!
I had planned on making just such a 'pg_dump' package -- but if the 7.3
pg_dump isn't going to produce useful output, it seems like a waste of time.
However, the jury is still out -- what sort of percentages are involved? That
is, how likely are problems going to happen?
Bruce, I mentioned a sed/perl/awk script already to massage the dump into a
7.3-friendly form -- but we need to gather the cases that are involved.
Methinks every single OpenACS installation will hit this issue.
How big is the problem? It's looking bigger with each passing day, ISTM.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
