Re: RPMS for 7.3 beta.

On Wednesday 18 September 2002 12:55 am, Tom Lane wrote:
> Lamar Owen <lamar(dot)owen(at)wgcr(dot)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