Skip site navigation (1) Skip section navigation (2)

Re: Unsupported 3rd-party solutions (Was: Few questions

From: Jan Wieck <JanWieck(at)Yahoo(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Thomas Hallgren <thhal(at)mailblocks(dot)com>,pgsql-general(at)postgresql(dot)org
Subject: Re: Unsupported 3rd-party solutions (Was: Few questions
Date: 2004-08-24 03:34:35
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
Is this one more incarnation of the packaging, release-announce and what 
has to be CORE or not discussions?

Well, the fact that the discussion is going on and on does indicate that 
the project "management" doesn't do a good job here. We have repeatedly 
stated that the core project doesn't have the time, resources or 
whatever to evaluate all those auxilliary projects and therefore we 
can't put together a list of recommendations. I think this true ... in part.

The true part is that the core project (not the CORE team alone) does 
not have the resources to review or evaluate all this. We probably don't 
even have the skillset to make any educated guesses about it. But I 
would say this is true about every project I ever have been a member of 
or every job I have been in.

Probably one of the outstanding abilities of the best managers I have 
ever worked for is "management by deligation". This does not mean to 
deligate work, but to deligate decisions. And then to go with that 
decision, accept it and to defend it.

Just because we don't have the skillset ourselves cannot mean that we 
leave the PostgreSQL user community in a decision vacuum. I don't think 
anyone really likes to be responsible for decisions he didn't make. But 
I guess that is what we have to do because our continuous "we don't 
know, it's your choice, pick your own poison" is just not what anyone 
wants to hear. And interestingly it is what most of us do anyway. How 
many of us really have the skillset to make an educated decision about 
the exact implementation of PITR features, the best strategy for buffer 
replacement, how to start/stop/throttle background writing of dirty 
buffers or why and when xid's should get frozen or not? Honestly, I do 
not know the answers to most of the questions that have to be decided 
inside of the core server these days either because I don't have the 
skillset or because I didn't have the time to figure it all out myself. 
Does that mean that I will not have to defend the way we do savepoints 
tomorrow? Nope, I will have to live with it and carry that decision to 
shows and events and everywhere as if it was my own one.

Now what is exactly the difference between those "core" feature 
decisions and the "auxiliary" or "3rd party" things? The fact that their 
code isn't part of our tarball is only an excuse for not making any 
recommendations. I don't care what type of admin tool the PostgreSQL 
community suggests for package maintainers to include in every standard 
installation of our database. I don't use any of them myself. But every 
single of them is certainly a lot better that our repeated *shrug*.

If we need user- or community votings on this, then lets do them. Let us 
stop telling people that nothing is good enough to be recommended by the 
PostgreSQL team. It is not true. There are a lot of things and add on 
products out there that are. And if 70% of our users vote for "C", then 
putting that onto a recommenation list is certainly not the worst.


On 8/23/2004 5:25 PM, Bruce Momjian wrote:

> As an example, who has the largest 8.0beta1 downloads?  pginstaller. 
> And who controls that?  The pginstaller project team.  It has no
> official relationship to anyone except it is a useful project and we
> mention it in the release notes.
> ---------------------------------------------------------------------------
> Thomas Hallgren wrote:
>> Marc G. Fournier wrote:
>> >
>> > As Tom (I believe) has stated, and both Bruce/I have said over and 
>> > over again ... this is nothing stop'ng a group of ppl starting up a 
>> > "bundled postgresql" project, and dedicating their time and effort 
>> > into building something up ...
>> >
>> > As Peter has stated, he had thought of this in the past, and felt it 
>> > was easier/better for the various OS distributions to do it on their 
>> > own ...
>> >
>> > In fact, Linux and FreeBSD *both* already deal with this in their 
>> > RPM/ports collections ... and, in fact, on the FreeBSD side, smaller 
>> > is better then larger, so that packager maintainers don't hvae to 
>> > download a 12Meg file to get a 1Meg port out of it ...
>> >
>> Bruce Momjian wrote:
>> >We are not adverse to someone taking the core db code, adding other
>> >stuff, and making a new super distribution.
>> >  
>> >
>> Your customers and many of your contributors would really like to see
>> PostgreSQL become more then just the core backend. A Redhat bundle is
>> great if your'e a Redhat user. If you are on another platform however,
>> it's no good to you. And some bundle from "a group of ppl" or "someone"?
>> No, sorry, that won't cut it either. It's just not the same thing at all.
>> Regards,
>> Thomas Hallgren
>> ---------------------------(end of broadcast)---------------------------
>> TIP 7: don't forget to increase your free space map settings

# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck(at)Yahoo(dot)com #

In response to


pgsql-general by date

Next:From: Bruce MomjianDate: 2004-08-24 03:37:33
Subject: Re: Unsupported 3rd-party solutions (Was: Few questions
Previous:From: Tom LaneDate: 2004-08-24 02:47:28
Subject: Re: UTF-8 and LIKE vs =

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group