Re: RPMS for 7.3 beta. - Mailing list pgsql-hackers

On Wednesday 18 September 2002 12:55 am, Tom Lane wrote:
> Lamar Owen <lamar.owen@wgcr.org> writes:
> > Not talking about a freeze.  Talking about separation of system/feature
> > metadata from user metadata that wouldn't change in the upgrade anyway --

> But the system catalogs *store* that metadata.

They _currently_ store the user's metadata.  But that's my point -- does the 
user metadata that isn't typically substantially different after going 
through a dump/reload _have_ to coexist with the system data which is 
intrinsic to the basic backend operation?

Yes, I know I'm talking about refactoring/renormalizing the system catalogs.  
And I know that's neither interesting nor 'fun'.  And a major undertaking.

> from?  None of the key developers care to spend their time that way;
> all of us have other issues that we find more interesting/compelling/fun.
> Unless someone of key-developer caliber comes along who *likes* spending
> time on upgrade issues, it's not going to get better.  Sorry to be the
> bearer of bad news, but that's reality as I see it.

Quoting myself from my reply a couple of hours ago to Chris:
-> While I should know better, I'm going to reply.....:-)
[snip]
-> I wish (in a somewhat wistful, yet futile manner) that each change was 
-> accompanied by data migration strategies for that change, but I'm not 
-> holding my breath, since the core developers have more important things
-> to do.  (Not being sarcastic -- just observing a fact).

You're not telling me something I don't already know in your paragraph, Tom.  
Data migration of real users isn't interesting, compelling, or fun.  That's 
been made abundantly clear the last ten times the subject of upgrading has 
come up.  What's a real-world user to do?  Find it interesting, compelling, 
and fun to work around our shortcoming? (here comes one of those paroxysms 
that will keep me awake tonight....)

I for one am not doing _this_ because I find it to be 'fun'.  Quite the 
opposite -- you try to help people who end up cussing you out for something 
you can't control.  (And I see all those messages addressed to Tom coming 
through the lists, so I'm sure Tom is no stranger to this portion of the 
project, either)  

I'm doing _this_ to try to help people not go through what I went through, as 
well as to try to help the project in general, for both selfish and selfless 
reasons.  If I were able to spend enough time on the issue I am quite 
confident I could find a solution, in a year or so.  But I find it 
compelling, if nothing else, to put food on my kids' plates, which precludes 
me working much on this particular issue.  But I do what I can, if nothing 
else.

But it is _necessary_ to migrate data for one reason or another.  Lack of 
distributed backports for security patches, that are official releases, is 
one quite compelling reason to go through an upgrade.

Chris, this is why I was somewhat reticent to reply before.  I've been down 
this dead-end road before.  To distill Tom's comments:
It is technically feasible to make a better (not perfect) upgrade path, but 
nobody that can do it wants to.

What good is an interesting, compelling, fun, featureful, new version if 
nobody ugrades to it due to migration difficulties?  This release could be 
the harbinger of further difficulties, I fear.

So, that's why I'm unhappy, to answer a question asked quite a while back in 
the thread.  

Back on topic: I'll work towards using the 7.3 pg_dump unless the 7.2 dump can 
be easily restored.  Given the desireability for opaque to go away soon, if 
the 7.3 pg_dump Does The Right Thing and creates an opaque-free dump, that in 
itself is enough reason to go that route, as it helps the user create a 
nonambiguous data dump.  If it helps the user it is typically a Good Thing, 
and I am willing to put the effort into that.  And it may prove to not be 
that bad -- I'll know in a few days, hopefully.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11