Re: State of Beta 2

With all the discussion and pg_upgrade, I saw no one offer to work on
it.

Does someone want to convert it to Perl? I think that would be a better
language than shell script for this purpose, and C is too low-level.

---------------------------------------------------------------------------

Lamar Owen wrote:
> Marc G. Fournier wrote:
> > On Mon, 15 Sep 2003, Joshua D. Drake wrote:
> >>>I'm not going to rehash the arguments I have made before;
>
> >>I at no point suggested that there was not a need. I only suggest that
> >>the need may not be as great as some suspect or feel. To be honest -- if
> >>your arguments were the "need" that everyone had... it would have been
> >>implemented some how. It hasn't yet which would suggest that the number
>
> > Just to add to this ... Bruce *did* start pg_upgrade, but I don't recall
> > anyone else looking at extending it ... if the *need* was so great,
> > someone would have step'd up and looked into adding to what was already
> > there ...
>
> You'ns are going to make a liar out of me yet; I said I wasn't going to
> rehash the arguments. But I am going to answer Marc's statement. Need
> of the users != developer interest in implementing those. This is the
> ugly fact of open source software -- it is developer-driven, not
> user-driven. If it were user-driven in this case seamless upgrading
> would have already happened. But the sad fact is that the people who
> have the necessary knowledge of the codebase in question are so
> complacent and comfortable with the current dump/reload cycle that they
> really don't seem to care about the upgrade issue. That is quite a
> harsh statement to make, yes, and I know that is kind of
> uncharacteristic for me. But, Marc, your statement thoroughy ignores
> the archived history of this issue on the lists.
>
> While pg_upgrade was a good first step (and I applaud Bruce for working
> on it), it was promptly broken because the developers who changed the
> on-disk format felt it wasn't important to make it continue working.
>
> Stepping up to the plate on this issue will require an intimate
> knowledge of the storage manager subsystem, a thorough knowledge of the
> system catalogs, etc. This has been discussed at length; I'll not
> repeat it. Just any old developer can't do this -- it needs the
> long-term focused attention of Tom, Jan, or Bruce. And that isn't going
> to happen. We know Tom's take on it; it's archived. Maybe there's
> someone out there with the deep knowledge of the backend to make this
> happen who cares enough about it to make it happen, and who has the time
> to do it. I care enough to do the work; but I have neither the deep
> knowledge necessary nor the time to make it happen. There are many in
> my position. But those who could make it happen don't seem to have the
> care level to do so.
>
> And that has nothing to do with user need as a whole, since the care
> level I mentioned is predicated by the developer interest level. While
> I know, Marc, how the whole project got started (I have read the first
> posts), and I appreciate that you, Bruce, Thomas, and Vadim started the
> original core team because you were and are users of PostgreSQL, I
> sincerely believe that in this instance you are out of touch with this
> need of many of today's userbase. And I say that with full knowledge of
> PostgreSQL Inc.'s support role. If given the choice between upgrading
> capability, PITR, and Win32 support, my vote would go to upgrading.
> Then migrating to PITR won't be a PITN.
>
> What good are great features if it's a PITN to get upgraded to them?
> --
> Lamar Owen
> Director of Information Technology
> Pisgah Astronomical Research Institute
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073