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

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

From: Thomas Hallgren <thhal(at)mailblocks(dot)com>
To: pgsql-general(at)postgresql(dot)org
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Unsupported 3rd-party solutions (Was: Few questions
Date: 2004-08-23 14:09:03
Message-ID: 4129FA7F.6010206@mailblocks.com (view raw or flat)
Thread:
Lists: pgsql-general
Marc,
> Since I (and I don't believe anyone else on core) uses Java ... 
> shouldn't it be up to the developer of the PL/J* modules to do this?  We 
> can't weigh which one is better then the other, as we don't use it ...
> 
Of course the contributors should supply as much of this material as 
possible. The point I'm trying to make is that there's often no 
incentive to do so, nor a good place to put it.

> Also, how does someone support something that they don't use?  Again, 
> that is the developer of PL/J*'s job to do, not ours ...
> 
Again, I'm not trying to offload work from the contributors onto the 
members of core. This is about how things are perceived by the 
PostgreSQL customers. Of course the contributors must continue to 
support their products. If they don't, I'd expect the "supported" status 
to be dropped at some point.

> At that rate, we'll have to distribute via CD to anyone that wants 
> PostgreSQL ... cause downloading it via FTP won't be a viable option 
> anymore :)
> 
In times when people download gigabytes of film and music using 
BitTorrent, I think that's the least of our problems. But of course, the 
distribution should be kept at a reasonable size. That's why I'd like a 
better solution to replace the inferior one and to limit the number of 
overlaps.

Regards,

Thomas Hallgren




In response to

Responses

pgsql-general by date

Next:From: Frank van VugtDate: 2004-08-23 14:14:22
Subject: Why does =ANY(<array>) need an extra cast when used on an array returned by a select?
Previous:From: Ennio-SrDate: 2004-08-23 13:59:40
Subject: Checking whether postgresql is running

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