Thread

contrib vs. gborg/pgfoundry for replication solutions

Jan Wieck <janwieck@yahoo.com> — 2004-04-21T17:48:48Z

Taking into account that quite a few people have repeatedly stated that 
the components in contrib are considered more supported/recommended than 
similar solutions found on gborg or any other external site, I suggest 
we move the projects dbmirror and dblink to gborg. The rserv contrib 
module seems to me to be an early Perl prototype of erserver, nobody is 
working on any more. I suggest we drop that entirely.

Comments/alternatives?


Jan

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

Re: contrib vs. gborg/pgfoundry for replication solutions

Joshua D. Drake <jd@commandprompt.com> — 2004-04-21T18:16:14Z

Hello,

My personal opinion is that contrib should be removed entirely. Just 
have a contrib.txt that says all contrib modules are at pgfoundry or 
whatever.

Sincerely,

Joshua D. Drake


Jan Wieck wrote:

> Taking into account that quite a few people have repeatedly stated that 
> the components in contrib are considered more supported/recommended than 
> similar solutions found on gborg or any other external site, I suggest 
> we move the projects dbmirror and dblink to gborg. The rserv contrib 
> module seems to me to be an early Perl prototype of erserver, nobody is 
> working on any more. I suggest we drop that entirely.
> 
> Comments/alternatives?
> 
> 
> Jan
>

Re: contrib vs. gborg/pgfoundry for replication solutions

Bruce Momjian <pgman@candle.pha.pa.us> — 2004-04-21T18:17:36Z

Jan Wieck wrote:
> Taking into account that quite a few people have repeatedly stated that 
> the components in contrib are considered more supported/recommended than 
> similar solutions found on gborg or any other external site, I suggest 
> we move the projects dbmirror and dblink to gborg. The rserv contrib 
> module seems to me to be an early Perl prototype of erserver, nobody is 
> working on any more. I suggest we drop that entirely.
> 
> Comments/alternatives?

Agreed.

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

Re: contrib vs. gborg/pgfoundry for replication solutions

Matthew T. O'Connor <matthew@zeut.net> — 2004-04-21T18:53:34Z

Joshua D. Drake wrote:

> Hello,
>
> My personal opinion is that contrib should be removed entirely. Just 
> have a contrib.txt that says all contrib modules are at pgfoundry or 
> whatever.

I'm not so sure that's a good idea.  I think contrib is a good 
repository for code that is tightly tied to the backend, or provides 
extentions to the backen, or is something that will eventually be 
integrated into the backend, but just isn't ready for prime time yet 
(pg_autovacuum for example).  The value of contrib is exposure.  I 
firmly believe that pg_autovacuum would not have gotten as much testing 
from gborg as it has from contrib.

Perhaps the definition of what should be in contrib should be tightened 
down, and anything that doesn't meet that definition should be removed, 
but I think contrib is a good concept.

Matthew

Re: contrib vs. gborg/pgfoundry for replication solutions

Tom Lane <tgl@sss.pgh.pa.us> — 2004-04-21T18:57:10Z

"Joshua D. Drake" <jd@commandprompt.com> writes:
> My personal opinion is that contrib should be removed entirely.

That's not real workable for code that is tightly tied to the backend,
such as the various GIST index extensions presently in contrib.  It's
just easier to maintain that code when it's in with the backend.

However the replication modules don't seem to have such a linkage,
so I have no objection to moving them out.

			regards, tom lane

Re: contrib vs. gborg/pgfoundry for replication solutions

Marc G. Fournier <scrappy@postgresql.org> — 2004-04-21T19:32:22Z

On Wed, 21 Apr 2004, Tom Lane wrote:

> "Joshua D. Drake" <jd@commandprompt.com> writes:
> > My personal opinion is that contrib should be removed entirely.
>
> That's not real workable for code that is tightly tied to the backend,
> such as the various GIST index extensions presently in contrib.  It's
> just easier to maintain that code when it's in with the backend.
>
> However the replication modules don't seem to have such a linkage,
> so I have no objection to moving them out.

Agreed ... but I also think that something like pg_autovacuum should be
moved to gborg ... there seems to be alot of activity on fixing bugs in it
that most ppl won't see until they upgrade to the next release, even
though those fixes would be pertinent/useful to their current
implementation ... begin able to download/install pg_autovacuum 1.1 would
definitely be a good thing, when it was considered stable enoguh for a
release ...

tsearch, I believe, is maintained somewhere else already, no?  same with
tsearch2?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Re: contrib vs. gborg/pgfoundry for replication solutions

Joshua D. Drake <jd@commandprompt.com> — 2004-04-21T19:47:09Z

> 
> tsearch, I believe, is maintained somewhere else already, no?  same with
> tsearch2?

Yes that is correct but I think they commit back to contrib before they 
release.

Realistically, although I did not used to agree, I believe that the only 
that that should come with PostgreSQL is PostgreSQL and required items 
for PostgreSQL.

IMHO: PostgreSQL should include:

PostgreSQL
Psql
All development headers
C/C++ Libs


Everything else should be on SourceForge or Gforge or whatever. The 
possible exception would be the pl stuff.

Sincerely,

Joshua D. Drake





> 
> ----
> Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
> Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Re: contrib vs. gborg/pgfoundry for replication solutions

Tom Lane <tgl@sss.pgh.pa.us> — 2004-04-21T19:49:06Z

"Marc G. Fournier" <scrappy@postgresql.org> writes:
> On Wed, 21 Apr 2004, Tom Lane wrote:
>> "Joshua D. Drake" <jd@commandprompt.com> writes:
>>> My personal opinion is that contrib should be removed entirely.
>> 
>> That's not real workable for code that is tightly tied to the backend,
>> such as the various GIST index extensions presently in contrib.  It's
>> just easier to maintain that code when it's in with the backend.

> tsearch, I believe, is maintained somewhere else already, no?  same with
> tsearch2?

No, those guys are exactly the sort of backend-dependent code I'm
thinking of.  Teodor just recently made a GIST API change that affected
both the core backend and tsearch (as well as the other GIST modules in
contrib).  With separate distribution trees that would've been a lot
more painful to do.

I think the long-term plan for tsearch2, at least, should be full
integration rather than separation ...

			regards, tom lane

Re: contrib vs. gborg/pgfoundry for replication solutions

scott.marlowe <scott.marlowe@ihs.com> — 2004-04-21T20:03:00Z

I almost agree, but I think things that are being actively developed to 
eventually move into the backend, like autovacuum or slony-I should be in 
contrib.  Things that aren't destined for backend integration should be 
removed though, like pgbench or dblink or whatnot.

On Wed, 21 Apr 2004, Joshua D. Drake wrote:

> Hello,
> 
> My personal opinion is that contrib should be removed entirely. Just 
> have a contrib.txt that says all contrib modules are at pgfoundry or 
> whatever.
> 
> Sincerely,
> 
> Joshua D. Drake
> 
> 
> Jan Wieck wrote:
> 
> > Taking into account that quite a few people have repeatedly stated that 
> > the components in contrib are considered more supported/recommended than 
> > similar solutions found on gborg or any other external site, I suggest 
> > we move the projects dbmirror and dblink to gborg. The rserv contrib 
> > module seems to me to be an early Perl prototype of erserver, nobody is 
> > working on any more. I suggest we drop that entirely.
> > 
> > Comments/alternatives?
> > 
> > 
> > Jan
> > 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>

Re: contrib vs. gborg/pgfoundry for replication solutions

Jan Wieck <janwieck@yahoo.com> — 2004-04-21T20:04:44Z

Joe Conway wrote:

> Jan Wieck wrote:
>> Taking into account that quite a few people have repeatedly stated that 
>> the components in contrib are considered more supported/recommended than 
>> similar solutions found on gborg or any other external site, I suggest 
>> we move the projects dbmirror and dblink to gborg. The rserv contrib 
>> module seems to me to be an early Perl prototype of erserver, nobody is 
>> working on any more. I suggest we drop that entirely.
>> 
>> Comments/alternatives?
> 
> dblink gets regularly updated as and when things change which affect it 
> in the backend. It is more tightly bond to the backend than a client 
> application, which the replication solutions you mention are. It is not 
> a replication solution anyway, so I'm not sure why you would categorize 
> in that way.

None of the replication solutions I see are client applications only. 
Substantial parts of erserver and Slony for example are loadable modules 
and stored procedures, tightly bond to the backend by using data and 
functionality not available via the SPI. So the same problems apply 
here, which then would be a reason to add them to contrib as well?


Jan

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

Re: contrib vs. gborg/pgfoundry for replication solutions

Oleg Bartunov <oleg@sai.msu.su> — 2004-04-21T20:41:28Z

The problem with moving all contribs to gborg is that sometimes it's
required to change many modules, for example, because of changing
GiST interface. Tom saves a lot of working for contrib authors, when he
change code in core. I'm not sure, gborg would provide easy access for
such kind of things. tsearch2, particularly, is maintained in pgsql CVS.

	Oleg
On Wed, 21 Apr 2004, Joshua D. Drake wrote:

>
> >
> > tsearch, I believe, is maintained somewhere else already, no?  same with
> > tsearch2?
>
> Yes that is correct but I think they commit back to contrib before they
> release.
>
> Realistically, although I did not used to agree, I believe that the only
> that that should come with PostgreSQL is PostgreSQL and required items
> for PostgreSQL.
>
> IMHO: PostgreSQL should include:
>
> PostgreSQL
> Psql
> All development headers
> C/C++ Libs
>
>
> Everything else should be on SourceForge or Gforge or whatever. The
> possible exception would be the pl stuff.
>
> Sincerely,
>
> Joshua D. Drake
>
>
>
>
>
> >
> > ----
> > Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
> > Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

	Regards,
		Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

Re: contrib vs. gborg/pgfoundry for replication solutions

Joshua D. Drake <jd@commandprompt.com> — 2004-04-21T20:53:15Z

Hello,

Well perhaps we can have exceptions. TSearch would be a good exception
as it really should be integrated into PostgreSQL anyway.

There are very few of these that I think would be an issue.

Sincerely,

Joshua D. Drake


Oleg Bartunov wrote:

> The problem with moving all contribs to gborg is that sometimes it's
> required to change many modules, for example, because of changing
> GiST interface. Tom saves a lot of working for contrib authors, when he
> change code in core. I'm not sure, gborg would provide easy access for
> such kind of things. tsearch2, particularly, is maintained in pgsql CVS.
> 
> 	Oleg
> On Wed, 21 Apr 2004, Joshua D. Drake wrote:
> 
> 
>>>tsearch, I believe, is maintained somewhere else already, no?  same with
>>>tsearch2?
>>
>>Yes that is correct but I think they commit back to contrib before they
>>release.
>>
>>Realistically, although I did not used to agree, I believe that the only
>>that that should come with PostgreSQL is PostgreSQL and required items
>>for PostgreSQL.
>>
>>IMHO: PostgreSQL should include:
>>
>>PostgreSQL
>>Psql
>>All development headers
>>C/C++ Libs
>>
>>
>>Everything else should be on SourceForge or Gforge or whatever. The
>>possible exception would be the pl stuff.
>>
>>Sincerely,
>>
>>Joshua D. Drake
>>
>>
>>
>>
>>
>>
>>>----
>>>Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
>>>Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 4: Don't 'kill -9' the postmaster
>>
> 
> 
> 	Regards,
> 		Oleg
> _____________________________________________________________
> Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
> Sternberg Astronomical Institute, Moscow University (Russia)
> Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
> phone: +007(095)939-16-83, +007(095)939-23-83

Re: contrib vs. gborg/pgfoundry for replication solutions

Marc G. Fournier <scrappy@postgresql.org> — 2004-04-21T23:07:01Z

On Wed, 21 Apr 2004, Tom Lane wrote:

> No, those guys are exactly the sort of backend-dependent code I'm
> thinking of.  Teodor just recently made a GIST API change that affected
> both the core backend and tsearch (as well as the other GIST modules in
> contrib).  With separate distribution trees that would've been a lot
> more painful to do.
>
> I think the long-term plan for tsearch2, at least, should be full
> integration rather than separation ...

But there should be some sort of path to full integration ...
isdb_ibbn(sp?) has been there forever, and I canj't see it ever being
integrated ...

Personally, the neat thing about PostgreSQL is that we are extendible(sp?)
quite easily, and stuff like tsearch, earthdistance, postgis, etc all show
that very nicely ... why add for the sake of adding?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Re: contrib vs. gborg/pgfoundry for replication solutions

Marc G. Fournier <scrappy@postgresql.org> — 2004-04-21T23:16:35Z

On Wed, 21 Apr 2004, scott.marlowe wrote:

> I almost agree, but I think things that are being actively developed to
> eventually move into the backend, like autovacuum or slony-I should be in
> contrib.  Things that aren't destined for backend integration should be
> removed though, like pgbench or dblink or whatnot.

Slony-I involves no backend integration that I've seen in its docs ...
Jan?  Did I miss something?

As far as stuff like autovacuum, though ... its something that could
definitely benefit from a seperate release cycle from the main code ...

Has anyone looked at developing an Installer/packaging system so that as
far as the code is concerned, thing are seperate projects, but for the end
user ...

The thing is, for how many ppl are seperate packages difficult?  I know
for me, under FreeBSD, I cd to a /usr/ports/databases/pg_autovacuum and
type 'make install' and its done ... I thought that stuff like Redhat had
the full screen installer that lists things?

My point is that all of this stuff shouldn't be in the core CVS ... its a
packaging issue, not a cvs one ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Re: contrib vs. gborg/pgfoundry for replication solutions

Marc G. Fournier <scrappy@postgresql.org> — 2004-04-21T23:18:06Z

On Wed, 21 Apr 2004, Jan Wieck wrote:

> Joe Conway wrote:
>
> > Jan Wieck wrote:
> >> Taking into account that quite a few people have repeatedly stated that
> >> the components in contrib are considered more supported/recommended than
> >> similar solutions found on gborg or any other external site, I suggest
> >> we move the projects dbmirror and dblink to gborg. The rserv contrib
> >> module seems to me to be an early Perl prototype of erserver, nobody is
> >> working on any more. I suggest we drop that entirely.
> >>
> >> Comments/alternatives?
> >
> > dblink gets regularly updated as and when things change which affect it
> > in the backend. It is more tightly bond to the backend than a client
> > application, which the replication solutions you mention are. It is not
> > a replication solution anyway, so I'm not sure why you would categorize
> > in that way.
>
> None of the replication solutions I see are client applications only.
> Substantial parts of erserver and Slony for example are loadable modules
> and stored procedures, tightly bond to the backend by using data and
> functionality not available via the SPI. So the same problems apply
> here, which then would be a reason to add them to contrib as well?

Why is it the core developers responsibility to make sure that an
application stays in sync with the main tree?  Personally, that is giving
life to software that could just as easily be unused by anyone, but kept
in the code base because "a commit was made to it less then 6 months ago"
...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Re: contrib vs. gborg/pgfoundry for replication solutions

Joshua D. Drake <jd@commandprompt.com> — 2004-04-21T23:31:30Z

> 
> The thing is, for how many ppl are seperate packages difficult?  I know
> for me, under FreeBSD, I cd to a /usr/ports/databases/pg_autovacuum and
> type 'make install' and its done ... I thought that stuff like Redhat had
> the full screen installer that lists things?

Well, if setup correctly for redhat, debian or even SuSE you would type:

apt-get install pg_autovacuum

or with redhat you might also do

yum install pg_autovacuum

But that is packaging and that is up to the developers of the particular 
project.

Joshua D. Drake




> 
> My point is that all of this stuff shouldn't be in the core CVS ... its a
> packaging issue, not a cvs one ...
> 
> ----
> Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
> Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Re: contrib vs. gborg/pgfoundry for replication solutions

Jan Wieck <janwieck@yahoo.com> — 2004-04-21T23:54:38Z

Marc G. Fournier wrote:
> On Wed, 21 Apr 2004, scott.marlowe wrote:
> 
>> I almost agree, but I think things that are being actively developed to
>> eventually move into the backend, like autovacuum or slony-I should be in
>> contrib.  Things that aren't destined for backend integration should be
>> removed though, like pgbench or dblink or whatnot.
> 
> Slony-I involves no backend integration that I've seen in its docs ...
> Jan?  Did I miss something?

Slony-I is intended to be PG version independent as much as possible. It 
would rather hurt to move it into contrib. Sure are there backend 
dependencies to #ifdef/#else, but for Slony-I this is considered a 
strength, not a problem. How else would it be possible to use Slony-I to 
do a PostgreSQL major version upgrade of multi-GB databases with only a 
few seconds interruption?

> 
> As far as stuff like autovacuum, though ... its something that could
> definitely benefit from a seperate release cycle from the main code ...
> 
> Has anyone looked at developing an Installer/packaging system so that as
> far as the code is concerned, thing are seperate projects, but for the end
> user ...
> 
> The thing is, for how many ppl are seperate packages difficult?  I know
> for me, under FreeBSD, I cd to a /usr/ports/databases/pg_autovacuum and
> type 'make install' and its done ... I thought that stuff like Redhat had
> the full screen installer that lists things?

I think most of the current contrib projects are more missing the 
advantage version independence would have for the ease of "sitting" in 
contrib and having the whole project management around them just done. 
Yes, doing your own gborg project costs time. You have to maintain 
pages, do your own release cycles with announcement, BETA phase, 
tarballs, packaging and all the nine yards. Being in contrib avoids all 
that in a very convenient way.

> 
> My point is that all of this stuff shouldn't be in the core CVS ... its a
> packaging issue, not a cvs one ...

Exactly.

Jan

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

Re: contrib vs. gborg/pgfoundry for replication solutions

Rod Taylor <pg@rbt.ca> — 2004-04-22T01:00:30Z

> I think most of the current contrib projects are more missing the 
> advantage version independence would have for the ease of "sitting" in 
> contrib and having the whole project management around them just done. 
> Yes, doing your own gborg project costs time. You have to maintain 
> pages, do your own release cycles with announcement, BETA phase, 
> tarballs, packaging and all the nine yards. Being in contrib avoids all 
> that in a very convenient way.

I think Gnome (and KDE) have the right idea. Several independent small
projects that once or twice a year get together and have a big release.

We could co-ordinate a set of projects (phppgadmin, pgadmin, slony,
jdbc, odbc, etc. etc.) to make a release on the same day as PostgreSQL.

We then setup several 'meta' packages. For example, PostgreSQL-lite
might be just the core. PostgreSQL-Advanced might include jdbc, pgadmin,
slony, tsearch, postgis and everything in postgresql-lite.

Those who know what they want would be free to install the individual
packages just like with Gnome you can install epiphany and it'll pull in
everything needed for it without any extras.

I suppose one trick is allowing things like Postgis to be compiled
without requiring the source code to be around -- although I suppose we
could suggest a postgresql-headers package which Mozilla did that for a
while.

Re: contrib vs. gborg/pgfoundry for replication solutions

Marc G. Fournier <scrappy@postgresql.org> — 2004-04-22T01:29:48Z

On Wed, 21 Apr 2004, Rod Taylor wrote:

> > I think most of the current contrib projects are more missing the
> > advantage version independence would have for the ease of "sitting" in
> > contrib and having the whole project management around them just done.
> > Yes, doing your own gborg project costs time. You have to maintain
> > pages, do your own release cycles with announcement, BETA phase,
> > tarballs, packaging and all the nine yards. Being in contrib avoids all
> > that in a very convenient way.
>
> I think Gnome (and KDE) have the right idea. Several independent small
> projects that once or twice a year get together and have a big release.
>
> We could co-ordinate a set of projects (phppgadmin, pgadmin, slony,
> jdbc, odbc, etc. etc.) to make a release on the same day as PostgreSQL.
>
> We then setup several 'meta' packages. For example, PostgreSQL-lite
> might be just the core. PostgreSQL-Advanced might include jdbc, pgadmin,
> slony, tsearch, postgis and everything in postgresql-lite.

I'd like to agree with this concept, but it falls way short of addressing
the problem ... and the problem isn't even pulling things out of contrib
... there are alot of good projects out there that aren't on gforge or in
the core distribution that ppl just aren't finding ...

a 'Meta Package' doesn't help much, since unless you put *everything* into
it that you can possibly find, there is always going to be something
missing that someone would find useful ... and if you put everything into
it, most ppl would only use a small percentage of what is there ...

People keep focusing on how to make a super-meta package ... the problem
isn't making one big package that contains it all, it is making sure that
what is available is easy to find ... what we need is something like
freshmeat that is *only* postgresql software ...

Now, Josh et al is working on finishing touches of he Projects web site
... I don't know everything that its able to do, but it does provide a
centralized, PostgreSQL specific, place to go to see what is available, as
long as ppl use it.

 ----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Re: contrib vs. gborg/pgfoundry for replication solutions

Joe Conway <mail@joeconway.com> — 2004-04-22T01:58:07Z

Marc G. Fournier wrote:
> Why is it the core developers responsibility to make sure that an
> application stays in sync with the main tree?  Personally, that is giving
> life to software that could just as easily be unused by anyone, but kept
> in the code base because "a commit was made to it less then 6 months ago"
> ...

Well, in the case of dblink, consider this:

- It is used by a fair number of people -- questions are answered on the
   lists at least once a week with "see contrib/dblink".

- It is dependent on backend code to the extent that it cannot be built
   outside of the contrib folder, unless some backend code is duplicated
   in the external project. It also has no build system of its own.

- dblink-type capability should someday make it into the backend, albeit
   in the form of something compliant to the SQL/MED spec. This is
   standard functionality in many of the RDBMSs that Postgres users
   migrate from, and it is needed by enterprise users.

- The maintenance burden on core developers is pretty minimal. Recent
   examples of where it was touched due to other changes in the backend
   are:

      * Tom - sort_mem to work_mem change
      * me - elog to ereport change
      * Neil - change to tuplestore_begin_heap declaration

    These changes were part of the routine "grep for all the affected
    code for the change I'm making", hence almost free (at least in my
    opinion, I'll let Tom or Neil object if they feel otherwise).

Had dblink been on gborg, they (Tom and Neil) never would have seen that 
their backend change affected it. It might have been weeks or months 
before anyone noticed that it no longer worked against cvs tip (possibly 
during beta for the next release). At that point the effort involved in 
figuring out why it no longer works, while not huge, is certainly not as 
small as the change-as-you-go approach we have now. I deal with this 
very issue for PL/R. I have to pay close attention to commit messages or 
I get bitten.

These same arguments apply to other things in contrib, and probably 
could apply to some that currently are not.

In any case, I don't understand what the driver is to kill contrib. I 
fully agree that it should be maintained (meaning that someone other 
than core is interested enough to provide patches if non-trivial 
maintenance is required to keep it compiling), and stuff that is not 
used or suitably licensed should be removed. The contrib build system 
ought to be maintained in working order in any case because it makes it 
far easier to extend Postgres with your own functions.

Anyway, just my 2cents.

Joe

Re: contrib vs. gborg/pgfoundry for replication solutions

Rod Taylor <pg@rbt.ca> — 2004-04-22T02:21:13Z

On Wed, 2004-04-21 at 21:29, Marc G. Fournier wrote:
> On Wed, 21 Apr 2004, Rod Taylor wrote:
> 
> > > I think most of the current contrib projects are more missing the
> > > advantage version independence would have for the ease of "sitting" in
> > > contrib and having the whole project management around them just done.
> > > Yes, doing your own gborg project costs time. You have to maintain
> > > pages, do your own release cycles with announcement, BETA phase,
> > > tarballs, packaging and all the nine yards. Being in contrib avoids all
> > > that in a very convenient way.
> >
> > I think Gnome (and KDE) have the right idea. Several independent small
> > projects that once or twice a year get together and have a big release.
> >
> > We could co-ordinate a set of projects (phppgadmin, pgadmin, slony,
> > jdbc, odbc, etc. etc.) to make a release on the same day as PostgreSQL.
> >
> > We then setup several 'meta' packages. For example, PostgreSQL-lite
> > might be just the core. PostgreSQL-Advanced might include jdbc, pgadmin,
> > slony, tsearch, postgis and everything in postgresql-lite.
> 
> I'd like to agree with this concept, but it falls way short of addressing
> the problem ... and the problem isn't even pulling things out of contrib
> ... there are alot of good projects out there that aren't on gforge or in
> the core distribution that ppl just aren't finding ...
> 
> a 'Meta Package' doesn't help much, since unless you put *everything* into
> it that you can possibly find, there is always going to be something
> missing that someone would find useful ... and if you put everything into
> it, most ppl would only use a small percentage of what is there ...

We have the current issue of people not knowing that projects like
pgadmin exist or where to find the jdbc drivers.

These basic components (and others a large segment uses that are well
maintained) should go through a release cycle with the -core including
the platform test/report phase and be prominently listed in the
downloads area and documentation areas -- just as we do for PostgreSQL
proper.

Goto http://postgresql.org, now track down the jdbc drivers or how to
use them. To a significant portion of our users this is more important
than CREATE FUNCTION is and in 7.5 jdbc documentation will be much more
difficult to find, but no less important than it used to be.

Another issue is organizing the hundreds of addon programs that do
everything from parsing logs and various specialized interfaces to
schema documentation and special function languages (plsh or plr).

With an upcoming windows release coming where the masses will be
watching, I think the former is more important at the moment.

Re: contrib vs. gborg/pgfoundry for replication solutions

Chris Browne <cbbrowne@acm.org> — 2004-04-22T02:25:29Z

A long time ago, in a galaxy far, far away, tgl@sss.pgh.pa.us (Tom Lane) wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
>> My personal opinion is that contrib should be removed entirely.
>
> That's not real workable for code that is tightly tied to the backend,
> such as the various GIST index extensions presently in contrib.  It's
> just easier to maintain that code when it's in with the backend.
>
> However the replication modules don't seem to have such a linkage,
> so I have no objection to moving them out.

I'll point out one "fly in ointment" that has been noticed; on AIX,
there are compilation tools that are difficult to live without, namely
"mkldexport.sh", that lives pretty deep in the source tree.

Maybe the answer is to "replicate" ;-) that into the code base for
code that uses it.  Alternatively, perhaps there needs to be a
"make-all-build-tools" target in the main makefile.

A challenge seems to be to have this play well with Linux and BSD
"package" systems; building packages that can automatically go to
sources (ala Ports or Source RPMs or auto-built .debs) for "contrib"
software is sure to be somewhat painful; doing the same for outside
code that also requires a PG source build is painful to think about.
-- 
"cbbrowne","@","ntlug.org"
http://www.ntlug.org/~cbbrowne/finances.html
Rules of the Evil Overlord #209. "I will not, under any circumstances,
marry a woman I know to be a faithless, conniving, back-stabbing witch
simply because I am absolutely desperate to perpetuate my family
line. Of course, we can still date." <http://www.eviloverlord.com/>

Re: contrib vs. gborg/pgfoundry for replication solutions

Marc G. Fournier <scrappy@postgresql.org> — 2004-04-22T02:43:57Z

On Wed, 21 Apr 2004, Rod Taylor wrote:

> We have the current issue of people not knowing that projects like
> pgadmin exist or where to find the jdbc drivers.

Agreed ... but makign one big META package isn't going to fix that ... as
someone else suggested, put a README file in the contrib directory that
points ppl to projects.postgresql.org ...

> These basic components (and others a large segment uses that are well
> maintained) should go through a release cycle with the -core including
> the platform test/report phase and be prominently listed in the
> downloads area and documentation areas -- just as we do for PostgreSQL
> proper.

*ack* ... now the beta cycle just quadrupled in length ... so we develop
for 4 months, and beta for a year while we make sure everyone else's
packages work with the -core?

Most DBAs that I know will not upgrade based on a .0 release on a
production system ... they will wait for at least a .1 release ... between
.0 and .1 is when projects like PgAdmin should be doing their testing to
make sure that they are good for the new major release ...

> Goto http://postgresql.org, now track down the jdbc drivers or how to
> use them. To a significant portion of our users this is more important
> than CREATE FUNCTION is and in 7.5 jdbc documentation will be much more
> difficult to find, but no less important than it used to be.

Now, out of all of the PostgreSQL users, what % are using JDBC?  What %
are using ODBC?  What percentage of those using JDBC are also using ODBC?
What % of those using PgAdmin are also using ODBC?  For that matter, how
many ppl using JDBC only want to download the .jar file itself, and not
the source code?  % of Binary-Only PgAdmin users?  ODBC driver?

The point of projects.postgresql.org is that if someone *is* looking for
an addon, they should be pointed to projects.postgresql.org ... if you try
and merge everything into the -core distribution, you are either going to
miss something that *someone* wants to use at some point, *or* one helluva
large tar file to download ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Re: contrib vs. gborg/pgfoundry for replication solutions

Marc G. Fournier <scrappy@postgresql.org> — 2004-04-22T02:47:11Z

On Wed, 21 Apr 2004, Joe Conway wrote:

> Well, in the case of dblink, consider this:
>
> - It is used by a fair number of people -- questions are answered on the
>    lists at least once a week with "see contrib/dblink".

A fair # of ppl are using erserver/bsd too ... should we add that in too?

> - It is dependent on backend code to the extent that it cannot be built
>    outside of the contrib folder, unless some backend code is duplicated
>    in the external project. It also has no build system of its own.

k, so this one falls under 'too lazy to build a proper build system'

> - dblink-type capability should someday make it into the backend, albeit
>    in the form of something compliant to the SQL/MED spec. This is
>    standard functionality in many of the RDBMSs that Postgres users
>    migrate from, and it is needed by enterprise users.

dblink isn't an integrated replication solution, it is a standalone one
... to date, I have not seen one replication solution that solves all the
issues, and unless someone comes up with the be all, end all replication
solution, none of them should be considered 'part of the backend' ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Re: contrib vs. gborg/pgfoundry for replication solutions

Jan Wieck <janwieck@yahoo.com> — 2004-04-22T02:54:54Z

Joe Conway wrote:
> Marc G. Fournier wrote:
>> Why is it the core developers responsibility to make sure that an
>> application stays in sync with the main tree?  Personally, that is giving
>> life to software that could just as easily be unused by anyone, but kept
>> in the code base because "a commit was made to it less then 6 months ago"
>> ...
> 
> Well, in the case of dblink, consider this:
> 
> - It is used by a fair number of people -- questions are answered on the
>    lists at least once a week with "see contrib/dblink".
> 
> - It is dependent on backend code to the extent that it cannot be built
>    outside of the contrib folder, unless some backend code is duplicated
>    in the external project. It also has no build system of its own.

Both very valid points and together they indicate a decision point ...

> 
> - dblink-type capability should someday make it into the backend, albeit
>    in the form of something compliant to the SQL/MED spec. This is
>    standard functionality in many of the RDBMSs that Postgres users
>    migrate from, and it is needed by enterprise users.

... which is right here.

Either dblink is vital, important and clean enough to move into the main 
backend code, then let's do it. You claim it is vital and important, but 
not clean? Then you know what to do.

> [...]
 >
> In any case, I don't understand what the driver is to kill contrib. I 
> fully agree that it should be maintained (meaning that someone other 
> than core is interested enough to provide patches if non-trivial 
> maintenance is required to keep it compiling), and stuff that is not 
> used or suitably licensed should be removed. The contrib build system 
> ought to be maintained in working order in any case because it makes it 
> far easier to extend Postgres with your own functions.

The driver from my point of view is that some things have been sitting 
in contrib for quite some time that are neither maintained, nor wanted 
by anyone. Don't take it personal, I just chose dbmirror and dblink 
because both fall to some degree into the same usage category as Slony, 
and both are active projects (I hate shooting at sitting ducks). If we 
can demonstrate that even projects as vital and complex as these two 
have a turning point where it says "into the backend or out of contrib", 
then things like "noupdate" or "userlock" will have a hard time to show 
any reason to make an exception.

> 
> Anyway, just my 2cents.
> 
> Joe

Cool ... found 2 cents :-)

Jan

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

Re: contrib vs. gborg/pgfoundry for replication solutions

Rod Taylor <pg@rbt.ca> — 2004-04-22T03:08:07Z

On Wed, 2004-04-21 at 22:43, Marc G. Fournier wrote:
> On Wed, 21 Apr 2004, Rod Taylor wrote:
> 
> > We have the current issue of people not knowing that projects like
> > pgadmin exist or where to find the jdbc drivers.
> 
> Agreed ... but makign one big META package isn't going to fix that ... as
> someone else suggested, put a README file in the contrib directory that
> points ppl to projects.postgresql.org ...

Considering the number of people asking about cross database queries,
anything in contrib will also be ignored.

It has to be on the front page of www.postgresql.org if we want people
to find it.

> > These basic components (and others a large segment uses that are well
> > maintained) should go through a release cycle with the -core including
> > the platform test/report phase and be prominently listed in the
> > downloads area and documentation areas -- just as we do for PostgreSQL
> > proper.
> 
> *ack* ... now the beta cycle just quadrupled in length ... so we develop
> for 4 months, and beta for a year while we make sure everyone else's
> packages work with the -core?

Come now. We all know of projects much much larger than PostgreSQL which
make more frequent releases.

This has nothing to do with timing, it has to do with organization. For
the most part the people working on the individual components of the
PostgreSQL Environment are different from those working on the core of
it. There is absolutely no reason we could not set a release date, stick
to it, and have all of the "important" projects ready for release at
that time.

> The point of projects.postgresql.org is that if someone *is* looking for
> an addon, they should be pointed to projects.postgresql.org ... if you try

I guess that is where we differ in opinion. pgadmin is not addon or an
enhancement, it is a part of the core project every bit as much as the
gnome-panel is a part of gnome. Sure, gnome-libs does all the heavy
lifting, but without the panel most users are lost.

Re: contrib vs. gborg/pgfoundry for replication solutions

Alvaro Herrera <alvherre@dcc.uchile.cl> — 2004-04-22T03:08:11Z

On Wed, Apr 21, 2004 at 11:47:11PM -0300, Marc G. Fournier wrote:
> On Wed, 21 Apr 2004, Joe Conway wrote:

> > - dblink-type capability should someday make it into the backend, albeit
> >    in the form of something compliant to the SQL/MED spec. This is
> >    standard functionality in many of the RDBMSs that Postgres users
> >    migrate from, and it is needed by enterprise users.
> 
> dblink isn't an integrated replication solution, it is a standalone one
> ... to date, I have not seen one replication solution that solves all the
> issues, and unless someone comes up with the be all, end all replication
> solution, none of them should be considered 'part of the backend' ...

You are thinking of dbmirror, while Joe talks about dblink.  It's
orthogonal functionality ...

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Cuando miro a alguien, más me atrae cómo cambia que quién es" (J. Binoche)

Re: contrib vs. gborg/pgfoundry for replication solutions

Jan Wieck <janwieck@yahoo.com> — 2004-04-22T03:08:24Z

Rod Taylor wrote:

>> I think most of the current contrib projects are more missing the 
>> advantage version independence would have for the ease of "sitting" in 
>> contrib and having the whole project management around them just done. 
>> Yes, doing your own gborg project costs time. You have to maintain 
>> pages, do your own release cycles with announcement, BETA phase, 
>> tarballs, packaging and all the nine yards. Being in contrib avoids all 
>> that in a very convenient way.
> 
> I think Gnome (and KDE) have the right idea. Several independent small
> projects that once or twice a year get together and have a big release.
> 
> We could co-ordinate a set of projects (phppgadmin, pgadmin, slony,
> jdbc, odbc, etc. etc.) to make a release on the same day as PostgreSQL.

Maybe not this way, but I like the general idea of "grouping" multiple 
smaller projects for release and overall project maintenance purposes.

CVS has the capability to combine multiple, separate modules into 
symbolic names. With that, one can create exactly those "meta" checkouts 
for nightly build systems, which could simply alarm a mailing list of 
module admins if something goes wrong. Setting up a nightly build agains 
CVS tip is nothing one would even think of for a simple loadable 
extension, but if you just have to add the thing to a group and done, 
Joe Conways concern is mostly answered.

Josh, is there anything that remotely sounds like this in the new system 
you're setting up?

Jan

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

Re: contrib vs. gborg/pgfoundry for replication solutions

Rod Taylor <pg@rbt.ca> — 2004-04-22T03:18:55Z

> The point of projects.postgresql.org is that if someone *is* looking for
> an addon, they should be pointed to projects.postgresql.org ... if you try
> and merge everything into the -core distribution, you are either going to
> miss something that *someone* wants to use at some point, *or* one helluva
> large tar file to download ...

Sorry, here is where we're talking across each-other. I do NOT want
everything in one tarball. I do think it is reasonable to make a
simultaneous release (different tarballs) and inform the packagers how
to put dependencies between the items.

/usr/ports/x11/gnome is a completely empty package. It's only purpose is
to install a standard list of elements that an end user may wish to have
on their desktop. Those who have seen gnome before and know what it has
to offer avoid the "large" package and go straight to the guts
installing the specific applications they want (pulling in library
dependencies automatically).


I for see us maintaining a list of the applications we believe that a
new user may want. That list should be packaged up via the appropriate
methods (dependency list is most obvious) for beginners with PostgreSQL.

These applications would be visible on the main website with
documentation, direct download links, etc. They can make independent
releases on their own, but are required to keep up to -core development.

Advanced users go for the components they want. Beginners get a
reasonably complete set of tools so they can actually get started with
development.


It has much more to do with how things are perceived by the beginning
user than how they are actually implemented.

Re: contrib vs. gborg/pgfoundry for replication solutions

Joshua D. Drake <jd@commandprompt.com> — 2004-04-22T03:57:49Z

Hello,

I believe that one problem with the contrib is that in order to build 
most of the contrib modules you need
the PostgreSQL source. That is silly. If I have PostgreSQL installed 
with all headers, I should be able to
download a PostgreSQL project app (pgAdmin whatever) and just build it 
against PostgreSQL.

Very few OSS projects are like that. If I want PHP I don't need Apache 
source, I just need the Apache
development stuff (headers etc...).

If we were to break out contrib so it was on its own, let people figure 
out their own build methods. You
don't "have" to use autoconf (although it is a good idea). You don't 
NEED PostgreSQL source etc...

Sincerely,

Joshua D. Drake


Marc G. Fournier wrote:

>On Wed, 21 Apr 2004, Rod Taylor wrote:
>
>  
>
>>We have the current issue of people not knowing that projects like
>>pgadmin exist or where to find the jdbc drivers.
>>    
>>
>
>Agreed ... but makign one big META package isn't going to fix that ... as
>someone else suggested, put a README file in the contrib directory that
>points ppl to projects.postgresql.org ...
>
>  
>
>>These basic components (and others a large segment uses that are well
>>maintained) should go through a release cycle with the -core including
>>the platform test/report phase and be prominently listed in the
>>downloads area and documentation areas -- just as we do for PostgreSQL
>>proper.
>>    
>>
>
>*ack* ... now the beta cycle just quadrupled in length ... so we develop
>for 4 months, and beta for a year while we make sure everyone else's
>packages work with the -core?
>
>Most DBAs that I know will not upgrade based on a .0 release on a
>production system ... they will wait for at least a .1 release ... between
>.0 and .1 is when projects like PgAdmin should be doing their testing to
>make sure that they are good for the new major release ...
>
>  
>
>>Goto http://postgresql.org, now track down the jdbc drivers or how to
>>use them. To a significant portion of our users this is more important
>>than CREATE FUNCTION is and in 7.5 jdbc documentation will be much more
>>difficult to find, but no less important than it used to be.
>>    
>>
>
>Now, out of all of the PostgreSQL users, what % are using JDBC?  What %
>are using ODBC?  What percentage of those using JDBC are also using ODBC?
>What % of those using PgAdmin are also using ODBC?  For that matter, how
>many ppl using JDBC only want to download the .jar file itself, and not
>the source code?  % of Binary-Only PgAdmin users?  ODBC driver?
>
>The point of projects.postgresql.org is that if someone *is* looking for
>an addon, they should be pointed to projects.postgresql.org ... if you try
>and merge everything into the -core distribution, you are either going to
>miss something that *someone* wants to use at some point, *or* one helluva
>large tar file to download ...
>
>----
>Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
>Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664
>  
>


-- 
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL

Re: contrib vs. gborg/pgfoundry for replication solutions

Joe Conway <mail@joeconway.com> — 2004-04-22T04:11:42Z

Marc G. Fournier wrote:
> On Wed, 21 Apr 2004, Joe Conway wrote:
>>- It is dependent on backend code to the extent that it cannot be built
>>   outside of the contrib folder, unless some backend code is duplicated
>>   in the external project. It also has no build system of its own.
> 
> k, so this one falls under 'too lazy to build a proper build system'

No, I don't call that lazy, I call it smart. It makes use (reuse) of a 
part of Postgres (the contrib build system) that is among its strengths. 
Is it your goal to make it harder for people to write their own C 
language functions? It makes no sense whatsoever to expect everyone who 
wants to extend Postgres to develop their own build system. I'd call 
that alot of duplicated effort -- effort better spent more productively.

> dblink isn't an integrated replication solution, it is a standalone one
> ... to date, I have not seen one replication solution that solves all the
> issues, and unless someone comes up with the be all, end all replication
> solution, none of them should be considered 'part of the backend' ...

No one (including me) has ever claimed it is any kind of a replication 
system. It is completely different functionality.

Joe

Re: contrib vs. gborg/pgfoundry for replication solutions

Karel Zak <zakkr@zf.jcu.cz> — 2004-04-22T06:40:47Z

On Thu, Apr 22, 2004 at 12:41:28AM +0400, Oleg Bartunov wrote:
> The problem with moving all contribs to gborg is that sometimes it's
> required to change many modules, for example, because of changing
> GiST interface. Tom saves a lot of working for contrib authors, when he
> change code in core. I'm not sure, gborg would provide easy access for
> such kind of things. tsearch2, particularly, is maintained in pgsql CVS.

 Agree. The basic  argue for removing  something from contrib  should be
 that nobody  maintain a module  or that maintain  it in the  contrib is
 difficult.

 Other problem  -- now  maintainers of distribution  PostgreSQL packages
 (Debian/RH/...) make packages from the  contrib tree. Are you sure they
 will search  something on sourceforge/gborg and  make separate packeges
 for each small script? How they will detect what is good for packaging?
 The contrib  tree is  basic selection of  interesting small  thigs from
 PostgreSQL world.

    Karel

-- 
 Karel Zak  <zakkr@zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/

Re: contrib vs. gborg/pgfoundry for replication solutions

Kris Jurka <books@ejurka.com> — 2004-04-22T07:53:45Z

On Wed, 21 Apr 2004, Marc G. Fournier wrote:

> On Wed, 21 Apr 2004, Rod Taylor wrote:
> 
> > We have the current issue of people not knowing that projects like
> > pgadmin exist or where to find the jdbc drivers.
> 
> Now, out of all of the PostgreSQL users, what % are using JDBC?  What %
> are using ODBC?  What percentage of those using JDBC are also using ODBC?
> What % of those using PgAdmin are also using ODBC?  For that matter, how
> many ppl using JDBC only want to download the .jar file itself, and not
> the source code?  % of Binary-Only PgAdmin users?  ODBC driver?
>

See the poll run on postgresql.org:
http://www.postgresql.org/survey.php?View=1&SurveyID=24

It took several minutes to load for me so I'll include the results here:
Currently the results of our "What PostgreSQL API do you use the most?"
survey are:

Answer		Responses	Percentage
libpq		1752		13.116%
libpq++		526		3.938%
libpqxx		176		1.318%
psqlODBC	2495		18.678%
JDBC		7607		56.947%
Npgsql		294		2.201%
ECPG		154		1.153%
pgtcl		354		2.650%
Total number of responses: 13358

You can certainly fault the choices (leaving perl, python, and php off the 
list), but 7500 java users is something that can't be ignored.

The point is that any legitimate database will provide JDBC and ODBC
drivers.  When new users can't immediately find them from the postgresql
home page they get frustrated and badmouth postgresql.  Telling them to go
to gborg isn't really helpful.  gborg is currently full of dead projects,
projects that have never had any code committed, and projects that are of
questionable utility.  gborg is supposed to be the dumping ground for 
these ala sourceforge, so it's not the dead projects I object to, so much 
as the fact that serious and critical projects are grouped together with 
them.

We need better packaging/promotion of secondary projects and the main
project can't be ignorant of this fact and cop out with "we just provide  
the server."

Kris Jurka

Re: contrib vs. gborg/pgfoundry for replication solutions

Mark Woodward <pgsql@mohawksoft.com> — 2004-04-22T17:00:04Z

> Taking into account that quite a few people have repeatedly stated that
> the components in contrib are considered more supported/recommended than
> similar solutions found on gborg or any other external site, I suggest
> we move the projects dbmirror and dblink to gborg. The rserv contrib
> module seems to me to be an early Perl prototype of erserver, nobody is
> working on any more. I suggest we drop that entirely.
>
> Comments/alternatives?

I love the idea, but (there is always a "but," isn't there?)

I agree with the notion that "contrib" be removed from the main
distribution. There is, however, a disconnect between supporting projects
and the main system.

Take a look at the www.postgresql.org web site.  Most people visually
filter out the side bars. I've been looking over effectiveness of paid
advertisements in the various search engines, and the numbers are clear in
that the paid links at the top of the page get the hits while the side
hits get almost completely ignored. What I think this means is that people
looking for projects will simply filter out any reference to gborg.

What would be good, is to bring gborg a little closer to PostgreSQL by
putting a link in the main site menu. Rather than:

"Download - Mirrors - Lists - Users - Developers - Docs - Search"

We could have:

"Download - Docs - Lists - Search - Community - Contrib"

"Download" would be a unified version of the Download/Mirrors links on the
current site.

"Docs" Unchanged
"Lists" Unchanged
"Search" Unchanged
"Community" is a unified Users/Developers page.
"Contrib" is a link to GBorg.

Re: contrib vs. gborg/pgfoundry for replication solutions

Barry Lind <blind@xythos.com> — 2004-04-22T17:55:04Z

Kris,

Thank you.  I objected to having the jdbc code moved out of the base 
product cvs tree for some of the reasons being discussed in this thread: 
  how are people going to find the jdbc driver, how will they get 
documentation for it, etc.

I think the core problem is that some people view postgres as just the 
database server proper.  But most people (IMHO) view postgres (or any 
database) as a set of things (core server, admin utils, drivers, etc).

I think the solution lies in improving www.postgresql.org.  At the end 
of the day it doesn't matter where source code lives, what matters is 
can people find what they are expecting.  Given we know what people are 
looking for, that should be front and center on the web site and the ftp 
sites.

--Barry

Kris Jurka wrote:
> 
> On Wed, 21 Apr 2004, Marc G. Fournier wrote:
> 
> 
>>On Wed, 21 Apr 2004, Rod Taylor wrote:
>>
>>
>>>We have the current issue of people not knowing that projects like
>>>pgadmin exist or where to find the jdbc drivers.
>>
>>Now, out of all of the PostgreSQL users, what % are using JDBC?  What %
>>are using ODBC?  What percentage of those using JDBC are also using ODBC?
>>What % of those using PgAdmin are also using ODBC?  For that matter, how
>>many ppl using JDBC only want to download the .jar file itself, and not
>>the source code?  % of Binary-Only PgAdmin users?  ODBC driver?
>>
> 
> 
> See the poll run on postgresql.org:
> http://www.postgresql.org/survey.php?View=1&SurveyID=24
> 
> It took several minutes to load for me so I'll include the results here:
> Currently the results of our "What PostgreSQL API do you use the most?"
> survey are:
> 
> Answer		Responses	Percentage
> libpq		1752		13.116%
> libpq++		526		3.938%
> libpqxx		176		1.318%
> psqlODBC	2495		18.678%
> JDBC		7607		56.947%
> Npgsql		294		2.201%
> ECPG		154		1.153%
> pgtcl		354		2.650%
> Total number of responses: 13358
> 
> You can certainly fault the choices (leaving perl, python, and php off the 
> list), but 7500 java users is something that can't be ignored.
> 
> The point is that any legitimate database will provide JDBC and ODBC
> drivers.  When new users can't immediately find them from the postgresql
> home page they get frustrated and badmouth postgresql.  Telling them to go
> to gborg isn't really helpful.  gborg is currently full of dead projects,
> projects that have never had any code committed, and projects that are of
> questionable utility.  gborg is supposed to be the dumping ground for 
> these ala sourceforge, so it's not the dead projects I object to, so much 
> as the fact that serious and critical projects are grouped together with 
> them.
> 
> We need better packaging/promotion of secondary projects and the main
> project can't be ignorant of this fact and cop out with "we just provide  
> the server."
> 
> Kris Jurka
> 
> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
>       joining column's datatypes do not match

Re: contrib vs. gborg/pgfoundry for replication solutions

Josh Berkus <josh@agliodbs.com> — 2004-04-22T19:24:31Z

Jan,

> Josh, is there anything that remotely sounds like this in the new system 
> you're setting up?

Not AFAIK.     I'm really not a CVS person (as you may have gathered), but I'm 
under the impression that GForge is a pretty "dumb" user of CVS.

As far as I'm concerned, what you've suggested is what we should be aiming 
toward -- and is a reason to consider Subversion or ARCH if that's what it 
takes.   We *do* need CPAN-like plugabbility, but unfortunately, I am too 
much of a collaboration neophyte to suggest how to construct one.

The reason to shrink contrib, from my perspective, is that we have too many 
associated projects to include them *all* in contrib -- we'd be talking a 
125MB download.    Many of these packages (the GUIs, for example) are 
redundant for any single user.  And, if we continue to be successful as an 
OSS project, we can expect the number of these packages to grow.

Which packages do and do not get included in /contrib has been a very 
arbitrary process to date -- mostly having to do with convenience and how 
involved the developer is on this list.   I started thinking of this when 
JDBC was moved out of contrib, over some protests, and started thinking,"why 
should DBMirror be in contrib and JDBC not?  Why is Tsearch in contrib and 
guid not?"

Overally, contrib continues to form a sort of "stamp of approval" that add-ins 
are "official" and part of PostgreSQL, while the stuff on GBorg is not.   
This is unfair to the very good and userful projects which are on Gborg, 
particularly considering the contrib items (like tsearch1 or postgres-r) 
which are depreciated even by thier original owners!

We can't have *everything* in contrib -- the top 5 GUIs alone would triple the 
size of our downloads.   So we need to move in the opposite direction -- 
putting more stuff in pgFoundry, and letting packagers know that they should 
package and include all "mature" projects on pgFoundry if they can.  (our 
earlier discussion proved that this list cannot realistically designate 
"approved" vs. "unapproved" projects).

-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco

Re: contrib vs. gborg/pgfoundry for replication solutions

Joe Conway <mail@joeconway.com> — 2004-04-22T21:18:53Z

Josh Berkus wrote:
> We can't have *everything* in contrib -- the top 5 GUIs alone would triple the 
> size of our downloads.   So we need to move in the opposite direction -- 
> putting more stuff in pgFoundry, and letting packagers know that they should 
> package and include all "mature" projects on pgFoundry if they can.  (our 
> earlier discussion proved that this list cannot realistically designate 
> "approved" vs. "unapproved" projects).
> 

As I've said on other parts of this thread, my concern with moving 
everything to gborg/pgFoundry is that it raises the bar in terms of 
difficulty if we expect every individual project to develop their own 
infrastructure. What we need to really make that work is to provide an 
infrastructure similar to Perl's CPAN or the R project's CRAN. Imagine 
how nice it would be if a relatively new Postgres user could do 
something like this at a shell prompt:

   pgFoundry install slony1
   pgFoundry install plr
   pgFoundry install tsearch2

That command would go to a standard URL (but maybe overridden by a 
configuration option, say to look at a specific mirror, maybe even with 
backup mirrors specified too) to grab a tarball, download it, untar it 
to some specific location locally, then run make, make install, make 
installcheck. The configuration information for the local Postgres 
install would need to be handy somewhere, support for installcheck, 
along with all headers (I'd think). I don't know all the details 
required to make this work, but it would be very useful. Thoughts?

Joe

Re: contrib vs. gborg/pgfoundry for replication solutions

Marc G. Fournier <scrappy@postgresql.org> — 2004-04-23T00:09:24Z

On Wed, 21 Apr 2004, Rod Taylor wrote:

> I guess that is where we differ in opinion. pgadmin is not addon or an
> enhancement, it is a part of the core project every bit as much as the
> gnome-panel is a part of gnome. Sure, gnome-libs does all the heavy
> lifting, but without the panel most users are lost.

No it isn't ... you don't need pgadmin, or jdbc, or libpgtcl, or ... to
run a PostgreSQL server ... you need the postgresql core, and, as things
are going, libpq and that is about it ... even psql is becoming less of a
requirement as the support utilities that have been using it move towards
C vs shell wrappers ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Re: contrib vs. gborg/pgfoundry for replication solutions

Rod Taylor <pg@rbt.ca> — 2004-04-23T01:00:22Z

On Thu, 2004-04-22 at 20:09, Marc G. Fournier wrote: 
> On Wed, 21 Apr 2004, Rod Taylor wrote:
> 
> > I guess that is where we differ in opinion. pgadmin is not addon or an
> > enhancement, it is a part of the core project every bit as much as the
> > gnome-panel is a part of gnome. Sure, gnome-libs does all the heavy
> > lifting, but without the panel most users are lost.
> 
> No it isn't ... you don't need pgadmin, or jdbc, or libpgtcl, or ... to
> run a PostgreSQL server ... you need the postgresql core, and, as things
> are going, libpq and that is about it ... even psql is becoming less of a
> requirement as the support utilities that have been using it move towards
> C vs shell wrappers ...

Thats actually my point. You don't need epiphany, gnome-panel, gcalc or
solitare to have a desktop you can use, but since a majority find those
items to be useful they have been included in the default desktop. Those
applications are not forced upon users who don't want them, nor are they
the only applications available.

The perception of PostgreSQL being difficult to use has very little to
do with the software itself. The decision has already been made that
MySQL is easy and PostgreSQL is difficult at the download page while the
user was trying to figure out if the software did what they require.

Simply put, nobody on this list is a typical PostgreSQL user. This is
shown by the simple fact that they care enough about the software to
have joined the list in the first place. A much more common PostgreSQL
user is someone who has been given a last minute task to complete and
wants to to get it over with as quickly as possible so they can go home.

Maybe I'm wrong. But I run into many more of the latter in my average
day than I do the former.

Re: contrib vs. gborg/pgfoundry for replication solutions

Tom Lane <tgl@sss.pgh.pa.us> — 2004-04-23T02:24:18Z

Joe Conway <mail@joeconway.com> writes:
> As I've said on other parts of this thread, my concern with moving 
> everything to gborg/pgFoundry is that it raises the bar in terms of 
> difficulty if we expect every individual project to develop their own 
> infrastructure.

I think that's exactly right.  It may be okay for the core project to
decide these little side projects are outside our responsibility ---
but what we had better take responsibility for is a framework within
which it's easy to maintain little side projects.  The cost of that
infrastructure is too high to expect the little projects to handle it
individually.

> What we need to really make that work is to provide an 
> infrastructure similar to Perl's CPAN or the R project's CRAN.

There's more than one issue.  CPAN makes it easy for end users to find
and install little projects.  We need that, but we also need to make it
easy for programmers to build and maintain those projects.  There was
some speculation earlier in the thread about whether the existing
contrib framework would do as a basis --- I don't know if it can be made
to work, or if it's sufficient, but it might do.  In any case we can't
just toss contrib modules over the side and expect that good things will
happen to them when they can't even be built outside the main tree.
The effort to fix that on a retail basis would alone guarantee that
they will be stillborn projects.

			regards, tom lane

Re: contrib vs. gborg/pgfoundry for replication solutions

Robert Treat <xzilla@users.sourceforge.net> — 2004-04-23T03:05:22Z

On Thursday 22 April 2004 13:55, Barry Lind wrote:
> I think the solution lies in improving www.postgresql.org.  At the end
> of the day it doesn't matter where source code lives, what matters is
> can people find what they are expecting.  Given we know what people are
> looking for, that should be front and center on the web site and the ftp
> sites.
>

But of course that solution always stalls out when it comes down to picking 
which projects get the special treatment of direct links from the main 
website and which ones stay out of the spotlight. With JDBC you might make 
the case that the comparable solutions are commercial code (though I suspect 
some of the commercial distributors might argue that) but with things like 
admin programs it gets even fuzzier as there are a whole slew of those 
available as open source projects.  If we include them all then we're back to 
square one, but I've never seen anyone eager to make the decision of which 
apps are "best" nor anyone terrible willing to let someone else make that 
decision either.   

BTW It's not that I am against the idea (if you haven't seen it, check out 
http://dev.mysql.com/downloads/ for one implementation), it's just that it's 
a radical departure from "the way things have always been done" and I'm not 
confident that there would be enough support to make the changes.

Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Re: contrib vs. gborg/pgfoundry for replication solutions

Marc G. Fournier <scrappy@postgresql.org> — 2004-04-23T03:27:25Z

On Wed, 21 Apr 2004, Joe Conway wrote:

> > On Wed, 21 Apr 2004, Joe Conway wrote:
> No, I don't call that lazy, I call it smart. It makes use (reuse) of a
> part of Postgres (the contrib build system) that is among its strengths.
> Is it your goal to make it harder for people to write their own C
> language functions? It makes no sense whatsoever to expect everyone who
> wants to extend Postgres to develop their own build system. I'd call
> that alot of duplicated effort -- effort better spent more productively.

Then, like I mentined to Bruce, we should be looking at some sort of
template that those developers can work off of ... downloading an 11Meg
file to build a 2k module seems a wee bit excessive, no?

 >
> No one (including me) has ever claimed it is any kind of a replication
> system. It is completely different functionality.

Sorry, my bad here ... I was mixing dblink with dbmirror ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Re: contrib vs. gborg/pgfoundry for replication solutions

Bruce Momjian <pgman@candle.pha.pa.us> — 2004-04-23T03:28:46Z

Tom Lane wrote:
> Joe Conway <mail@joeconway.com> writes:
> > As I've said on other parts of this thread, my concern with moving 
> > everything to gborg/pgFoundry is that it raises the bar in terms of 
> > difficulty if we expect every individual project to develop their own 
> > infrastructure.
> 
> I think that's exactly right.  It may be okay for the core project to
> decide these little side projects are outside our responsibility ---
> but what we had better take responsibility for is a framework within
> which it's easy to maintain little side projects.  The cost of that
> infrastructure is too high to expect the little projects to handle it
> individually.
> 
> > What we need to really make that work is to provide an 
> > infrastructure similar to Perl's CPAN or the R project's CRAN.
> 
> There's more than one issue.  CPAN makes it easy for end users to find
> and install little projects.  We need that, but we also need to make it
> easy for programmers to build and maintain those projects.  There was
> some speculation earlier in the thread about whether the existing
> contrib framework would do as a basis --- I don't know if it can be made
> to work, or if it's sufficient, but it might do.  In any case we can't
> just toss contrib modules over the side and expect that good things will
> happen to them when they can't even be built outside the main tree.
> The effort to fix that on a retail basis would alone guarantee that
> they will be stillborn projects.

What if we create a build/ directory as part of install that
pg_config.h, Makefile.global, etc, anything a plugin would need, and
install it by default.  Then, if we give folks an easy way to access
them from their own apps and Makefiles, it would solve most of the
problems.

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

Re: contrib vs. gborg/pgfoundry for replication solutions

Bruce Momjian <pgman@candle.pha.pa.us> — 2004-04-23T03:51:55Z

Marc G. Fournier wrote:
> On Wed, 21 Apr 2004, Joe Conway wrote:
> 
> > > On Wed, 21 Apr 2004, Joe Conway wrote:
> > No, I don't call that lazy, I call it smart. It makes use (reuse) of a
> > part of Postgres (the contrib build system) that is among its strengths.
> > Is it your goal to make it harder for people to write their own C
> > language functions? It makes no sense whatsoever to expect everyone who
> > wants to extend Postgres to develop their own build system. I'd call
> > that alot of duplicated effort -- effort better spent more productively.
> 
> Then, like I mentined to Bruce, we should be looking at some sort of
> template that those developers can work off of ... downloading an 11Meg
> file to build a 2k module seems a wee bit excessive, no?

OK, I think the number of files needed to build modules is small and I
think can be installed by default in a /build directory.  I am thinking
that with a little script help, projects can build apps that look like
like Makefiles used in our core project.

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

Re: contrib vs. gborg/pgfoundry for replication solutions

Marc G. Fournier <scrappy@postgresql.org> — 2004-04-23T04:05:40Z

On Thu, 22 Apr 2004, Bruce Momjian wrote:

> OK, I think the number of files needed to build modules is small and I
> think can be installed by default in a /build directory.  I am thinking
> that with a little script help, projects can build apps that look like
> like Makefiles used in our core project.

This is all I'm saying ... its like when we packaged up our first eRServer
... I didn't require our clients to go out and download PostgreSQL to
build it, I pulled in the few files from our build environment into the
package so that it could be built independently ...

Nice thing was, we were able to hit as many platforms as PostgreSQL did,
as building shared libraries and such was all there ready to go ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Re: contrib vs. gborg/pgfoundry for replication solutions

Tom Lane <tgl@sss.pgh.pa.us> — 2004-04-23T04:09:47Z

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> What if we create a build/ directory as part of install that
> pg_config.h, Makefile.global, etc, anything a plugin would need, and
> install it by default.  Then, if we give folks an easy way to access
> them from their own apps and Makefiles, it would solve most of the
> problems.

No it wouldn't, because those files *do not work outside the build
tree*.  There are built-in assumptions about where the Makefiles
themselves live relative to the include tree, where the invoking module
is relative to all that, etc.  Certainly there are a couple of files we
need to install that we currently don't, but it's going to take some
actual work beyond that to fix the problem.  See for example
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=112244
and if you're interested try to fix it yourself; it didn't seem trivial
when I was poking at it.

The specific details aren't especially relevant to this thread, though.
What is relevant is that we agree to a commitment that we will make
it easy to build modules outside the current Postgres build environment,
and that we will have an ongoing commitment to make sure that that keeps
working.

			regards, tom lane

Re: contrib vs. gborg/pgfoundry for replication solutions

Greg Sabino Mullane <greg@turnstep.com> — 2004-04-23T11:37:30Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
 
> There's more than one issue. CPAN makes it easy for end users to find
> and install little projects.
 
One thing I would like to see is a more direct link to the drivers
(e.g. DBD::Pg, JDBC)  from the download page. I don't think they need to
live in contrib, but having them on the download page right next to
the latest PG server files would do wonders. All the maintainers of
external projects would have to do is make sure that the link points to
where they want it to.
 
For example. look at how MySQL handles the DBD::mysql client (which is
hosted at CPAN, not mysql).
 
http://dev.mysql.com/downloads/index.html
 
The download page above has the server links, a few others, and then:
 
"DBI -- for connecting to MySQL from Perl"
 
Clicking on "DBI" gives you a small, clean page that explains what DBI
is and gives links to DBI and DBD::mysql, both hosted on cpan.org.
 
- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200404230734
 
-----BEGIN PGP SIGNATURE-----
 
iD8DBQFAiQBDvJuQZxSWSsgRAqn5AJ4pEllgPCiTVfAcrK21r62RgD1tdACg4IHz
hAb4LBiqlIMbBF2bsXdZDDI=
=xPFb
-----END PGP SIGNATURE-----

Re: contrib vs. gborg/pgfoundry for replication solutions

Jan Wieck <janwieck@yahoo.com> — 2004-04-23T11:59:54Z

Tom Lane wrote:

> The specific details aren't especially relevant to this thread, though.
> What is relevant is that we agree to a commitment that we will make
> it easy to build modules outside the current Postgres build environment,
> and that we will have an ongoing commitment to make sure that that keeps
> working.

Agreed.


Jan

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

Re: contrib vs. gborg/pgfoundry for replication solutions

Fabien COELHO <fabien.coelho@ensmp.fr> — 2004-04-23T12:53:44Z

> > The specific details aren't especially relevant to this thread, though.
> > What is relevant is that we agree to a commitment that we will make
> > it easy to build modules outside the current Postgres build environment,
> > and that we will have an ongoing commitment to make sure that that keeps
> > working.

Maybe you try to mimic apache "apxs" script behavior?
It allows to compile, install, configure new modules into apache.

pg_config is not convincing at the time:

shell> pg_config --includedir-server
/usr/local/pg750a/include/postgresql/server

shell> ls /usr/local/pg750a/include/postgresql/server
ls: /usr/local/pg750a/include/postgresql/server: No such file or directory

Too bad, server headers are not installed by default:-(

-- 
Fabien.

Re: contrib vs. gborg/pgfoundry for replication solutions

Rod Taylor <pg@rbt.ca> — 2004-04-23T15:02:00Z

On Thu, 2004-04-22 at 23:05, Robert Treat wrote:
> On Thursday 22 April 2004 13:55, Barry Lind wrote:
> > I think the solution lies in improving www.postgresql.org.  At the end
> > of the day it doesn't matter where source code lives, what matters is
> > can people find what they are expecting.  Given we know what people are
> > looking for, that should be front and center on the web site and the ftp
> > sites.

> But of course that solution always stalls out when it comes down to picking 
> which projects get the special treatment of direct links from the main 
> website and which ones stay out of the spotlight. With JDBC you might make 

Most end users don't care if they can choose between 20 administration
interfaces. They want to know which one works the best and just use
that.

Guidelines:

1. Must be fully functional with new release of PostgreSQL on day of
PostgreSQL release -- all features. (Admin programs should know how to
create and manage all objects).

2. Must function across a majority of platforms that PostgreSQL
supports.

3. Must be available for free. Something we could *and will* distribute
via CD or could be installed by default. Likewise, source code must be
available to ensure it does not become discontinued.

4. Must be high quality -- equivalent to that of PostgreSQL itself.

5. It should be something that a company selling PostgreSQL support
would be willing to take on.

6. Must have demonstrated the above prior to inclusion on the download
page (gone through a full cycle).

7. They must be willing to change the name to something generic. I.e.
PostgreSQL Administration Interface or PostgreSQL Java Connector.

In other-words, they need to be willing to be a part of the larger
PostgreSQL community. If someone thinks that the JDBC drivers are
broken, the JDBC folks should be open to debate on how to solve the
issues or otherwise argue that there are no problems. Same as how
PostgreSQL itself works.

I really don't see this as being any different than deciding which
buffer strategy or website style to use. One is better in some way so it
becomes a part of the system.

Re: contrib vs. gborg/pgfoundry for replication solutions

Robert Treat <xzilla@users.sourceforge.net> — 2004-04-23T18:02:48Z

On Fri, 2004-04-23 at 11:02, Rod Taylor wrote:
> On Thu, 2004-04-22 at 23:05, Robert Treat wrote:
> > On Thursday 22 April 2004 13:55, Barry Lind wrote:
> > > I think the solution lies in improving www.postgresql.org.  At the end
> > > of the day it doesn't matter where source code lives, what matters is
> > > can people find what they are expecting.  Given we know what people are
> > > looking for, that should be front and center on the web site and the ftp
> > > sites.
> 
> > But of course that solution always stalls out when it comes down to picking 
> > which projects get the special treatment of direct links from the main 
> > website and which ones stay out of the spotlight. With JDBC you might make 
> 
> I really don't see this as being any different than deciding which
> buffer strategy or website style to use. One is better in some way so it
> becomes a part of the system.
> 

The difference is that a "better" admin tool is very subjective where as
a buffer strategy is not... or maybe the difference is really that
everyone thinks they are qualified to pick a "better" admin tool, but
very few can really argue as to a better buffer strategy. While I think
your criteria is pretty close to what I would use, I still couldn't pick
which is the best between pgtcl/pgtclng/pgintcl or pypgsql/pygresql...
and even I did I bet some people would have a problem with my choices. 

Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Re: contrib vs. gborg/pgfoundry for replication solutions

Matthew T. O'Connor <matthew@zeut.net> — 2004-04-23T18:17:54Z

>> On Thu, 2004-04-22 at 23:05, Robert Treat wrote:
> The difference is that a "better" admin tool is very subjective where as
> a buffer strategy is not... or maybe the difference is really that
> everyone thinks they are qualified to pick a "better" admin tool, but
> very few can really argue as to a better buffer strategy. While I think
> your criteria is pretty close to what I would use, I still couldn't pick
> which is the best between pgtcl/pgtclng/pgintcl or pypgsql/pygresql...
> and even I did I bet some people would have a problem with my choices.

I think the issue is that is gborg/pgfoundy should not just be a
sourceforge like tool for postgresql related applications.  If they are
then someone looking for a gui admin tool for exmaple has to try them all
out only to find that 75% of them are half started projects that haven't
been maintained in two years, at least that is my typical experience with
sourceforge, and I know that is an issue with gborg right now.

Perhaps we could have some type of system whereby we can rank apps that as
tier1 supported or some such thing.  The end user can still make his
subjective choice as to which is best, since nothing prevents us from
having 4 different tier1 supported gui admin apps, but the enduser would
be able to weed out most of the apps that aren't even close.

Re: contrib vs. gborg/pgfoundry for replication solutions

Rod Taylor <pg@rbt.ca> — 2004-04-23T18:46:15Z

> The difference is that a "better" admin tool is very subjective where as
> a buffer strategy is not... or maybe the difference is really that
> everyone thinks they are qualified to pick a "better" admin tool, but
> very few can really argue as to a better buffer strategy. While I think
> your criteria is pretty close to what I would use, I still couldn't pick
> which is the best between pgtcl/pgtclng/pgintcl or pypgsql/pygresql...
> and even I did I bet some people would have a problem with my choices. 

If you have a hard time picking between those projects, imagine the
difficulties someone who has never used PostgreSQL has just tracking
down the options available to them.

We would not be removing any choices for the user. We're simply
supplying a list of suggested tools that they may have interest in.

Getting the user to download PostgreSQL and give it a shot without
becoming frustrated because the "basics" were not available (in an
obvious location) is the first step.

Step 2 is to inform the user that there are more alternatives available.
I see pgFoundary doing a good job of #2 -- but it is not going to help
with #1 (too much choice is as bad as none at all to a beginner).

Re: contrib vs. gborg/pgfoundry for replication solutions

jearl@bullysports.com — 2004-04-23T19:22:54Z

Rod Taylor <pg@rbt.ca> writes:

>> The difference is that a "better" admin tool is very subjective where as
>> a buffer strategy is not... or maybe the difference is really that
>> everyone thinks they are qualified to pick a "better" admin tool, but
>> very few can really argue as to a better buffer strategy. While I think
>> your criteria is pretty close to what I would use, I still couldn't pick
>> which is the best between pgtcl/pgtclng/pgintcl or pypgsql/pygresql...
>> and even I did I bet some people would have a problem with my choices. 
>
> If you have a hard time picking between those projects, imagine the
> difficulties someone who has never used PostgreSQL has just tracking
> down the options available to them.

Exactly.  MySQL makes no bones about choosing "blessed" projects.  I
don't think that MySQL AB's MySQL Control Center is the best MySQL
GUI, but it's better than the "default" PostgreSQL choice.  MySQL
shoves a workable solution under the end user's nose.  PostgreSQL
gives the potential user a wide array of choices, none of which are
particularly easy to find.  How many GUI tools are listed on GBorg?
How many potential users even know to look at GBorg at all?

One thing is certain most users aren't going to find psql (probably
compiled without readline support) comparable with MySQL Control
Center.  Not to mention the fact that not having a set of "blessed"
tools means that we end up with competing tools.  PostgreSQL has
several replication toolsets, piles of admin tools, and several
competing language bindings for some of the most popular development
languages.

How many Python bindings does PostgreSQL need?

PostgreSQL has some amazing supporting tools, but they are all hidden
in an unlighted basement in a locked filing cabinet next to a sign
that reads "Beware of the Leopard."

> We would not be removing any choices for the user. We're simply
> supplying a list of suggested tools that they may have interest in.

Exactly.  Yes, choosing tools requires some politics, and it will
inevitably make some users and developers upset because their projects
will get passed over for more popular ones.  However, this will
certainly help new users that are looking at PostgreSQL for the first
time.  They will be able to see, right off, what *sort* of tools are
available for use with PostgreSQL.  Later on as these people become
part of the PostgreSQL community they might even find out about
alternative tools that they like better.

> Getting the user to download PostgreSQL and give it a shot without
> becoming frustrated because the "basics" were not available (in an
> obvious location) is the first step.

PostgreSQL stacks up well as a database.  In fact, it rocks.  But
comparing plain Jane PostgreSQL against other databases and their
assorted suite of tools is not going to work in PostgreSQL's favor.
Fortunately PostgreSQL has comparable supporting tools as well.
Unfortunately no one knows about these tools except for those of us on
the PostgreSQL lists.

> Step 2 is to inform the user that there are more alternatives available.
> I see pgFoundary doing a good job of #2 -- but it is not going to help
> with #1 (too much choice is as bad as none at all to a beginner).

Precisely.  The trick is to promote PostgreSQL and a core set of
tools.  These tools don't have to be part of PostgreSQL's CVS (or even
be available for download) from the postgresql.com site, but they
should receive "top" billing.  When the end user looks for a GUI,
there should be a single solitary GUI that should be the "default"
choice.  When the end user asks about replication they should be
guided to a single solution.  In cases where it is difficult to decide
what the default case might be--like in the case of replication where
the tools you will want to use depends on what you are trying to
accomplish--simply point users at the most common scenario and then
document that they might need to use other tools to solve different
problems.

Jason

Re: contrib vs. gborg/pgfoundry for replication solutions

Andrew Sullivan <ajs@crankycanuck.ca> — 2004-04-23T19:34:42Z

On Fri, Apr 23, 2004 at 01:05:40AM -0300, Marc G. Fournier wrote:
> 
> This is all I'm saying ... its like when we packaged up our first eRServer
> ... I didn't require our clients to go out and download PostgreSQL to
> build it, I pulled in the few files from our build environment into the
> package so that it could be built independently ...

I am the last person in the world to cast aspersions on anyone's
packaging, but I'm not sure holding erserver up as a paradigm case of
easy compilation outside the main build tree is going to make your
argument easier here.

A

-- 
Andrew Sullivan  | ajs@crankycanuck.ca

Re: contrib vs. gborg/pgfoundry for replication solutions

Marc G. Fournier <scrappy@postgresql.org> — 2004-04-24T03:11:36Z

On Thu, 22 Apr 2004 pgsql@mohawksoft.com wrote:

> "Download - Mirrors - Lists - Users - Developers - Docs - Search"
>
> We could have:
>
> "Download - Docs - Lists - Search - Community - Contrib"
>
> "Download" would be a unified version of the Download/Mirrors links on the
> current site.

I don't agree with this, since mirrors are web mirrors ... but I do like
the 'Contrib' pointing to gborg/projects ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Re: contrib vs. gborg/pgfoundry for replication solutions

Tom Lane <tgl@sss.pgh.pa.us> — 2004-04-24T04:42:26Z

"Marc G. Fournier" <scrappy@postgresql.org> writes:
> I don't agree with this, since mirrors are web mirrors ... but I do like
> the 'Contrib' pointing to gborg/projects ...

Yeah, I like the contrib link idea too.  Much of the recent discussion
comes down to gborg not being visible enough.

However ... how do we handle things once pgfoundry is online too?

(I suppose two links labeled "Old Contrib" and "New Contrib" might serve
as a forcing function to get projects to migrate over ;-))

			regards, tom lane

Re: contrib vs. gborg/pgfoundry for replication solutions

Mark Woodward <pgsql@mohawksoft.com> — 2004-04-24T15:53:52Z

> "Marc G. Fournier" <scrappy@postgresql.org> writes:
>> I don't agree with this, since mirrors are web mirrors ... but I do like
>> the 'Contrib' pointing to gborg/projects ...
>
> Yeah, I like the contrib link idea too.  Much of the recent discussion
> comes down to gborg not being visible enough.
>
> However ... how do we handle things once pgfoundry is online too?
>
> (I suppose two links labeled "Old Contrib" and "New Contrib" might serve
> as a forcing function to get projects to migrate over ;-))
>

If there is going to be a change, i.e. Great Bridge is going away, and
being replaced with pgfoundary, I would suggest that you notify everyone
of a date and make it happen. Conversely, on pgfoundary, make a link to
gborg calling it "old projects" or something like that.

Take a look at this mock-up:
http://www.mohawksoft.com/PostgreSQL.html

(I am not a good web developer, I just moved a few things around, but I
hope you get what I'm trying to say)

A good web design makes no assumption that the visitor knows anything
about you. Like "mirrors" or "download," whis would tend to confuse first
time visitors. A single "Download" link should take the user to a page
that explains http/ftp and provides the various source links. Similarly, a
"Contrib" should take the user to a single place, gborg now, pgfoundary
later. Pgfoundary can then direct them to gborg if the project they are
searching for is not there.

The main problem with hard to use or "cluttered" web sites is that techies
like ourselves tend to put too much up front. Simple is better. Open up a
browser window on www.PostgreSQL.org. Don't resize window, assume 1024x768
screen, and maybe 3/4 or 2/3 of the screen is taken by the browser Window.
What do you see?

You have to scroll to see gborg and the odbc driver and replication, two
very important projects. All the visual clues needed to find things need
to be seen in that first window or people will not see them. In my screen,
the bottom says "User Survey" and "Websites" There are no visual clues
that something like gborg would show up if I scrolled down.

Yes, you can "The user should just scroll down," but they don't. Period.
It is like the first paragraph in a news article, if you don't grap the
user there, you won't.

Lastly there is grouping and relevence. Why is gborg lower on the page
than "User Survey?" Isn't gborg more important to the users than the user
survey?  Why are there two links to gborg, one under websites and the
other under gborg, abd both are under the scroll line. Why is there a link
to "mailing list archives" under websites and as a top level link on the
menu?

All this critisizm aside, I generally like the look of the website, even
thought the elephant banner doesn't line up with the PostgreSQL banner :-)
It is just that the content and the presentation can be streamlined,
taking out redundant links and info, removing logically similar choices
i.e. "Download" and "Mirrors," adding "Contrib," and organizing more
important stuff at the top and down the middle, with less relvent stuff to
the right.

Re: contrib vs. gborg/pgfoundry for replication solutions

Andrew Sullivan <ajs@crankycanuck.ca> — 2004-04-26T18:01:43Z

On Wed, Apr 21, 2004 at 10:25:29PM -0400, Christopher Browne wrote:
> 
> I'll point out one "fly in ointment" that has been noticed; on AIX,
> there are compilation tools that are difficult to live without, namely
> "mkldexport.sh", that lives pretty deep in the source tree.

That's just a problem to do with autoconf.  All we gots to do is find
an autoconf genius.  I don't think it entails that we need a complete
built source tree for everything.

A

-- 
Andrew Sullivan  | ajs@crankycanuck.ca