Re: State of Beta 2

Поиск
Список
Период
Сортировка
От Lamar Owen
Тема Re: State of Beta 2
Дата
Msg-id 3F6715BB.4040107@pari.edu
обсуждение исходный текст
Ответ на Re: State of Beta 2  ("Marc G. Fournier" <scrappy@postgresql.org>)
Ответы Re: State of Beta 2  (Kaare Rasmussen <kar@kakidata.dk>)
Re: State of Beta 2  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: State of Beta 2  (Mike Mascari <mascarm@mascari.com>)
Re: State of Beta 2  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-general
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



В списке pgsql-general по дате отправления:

Предыдущее
От: "scott.marlowe"
Дата:
Сообщение: Re: CONCAT function
Следующее
От: Richard Huxton
Дата:
Сообщение: Re: CONCAT function