contrib vs. gborg/pgfoundry for replication solutions

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:

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

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

"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

-----Original Message-----
From: Joshua D. Drake [mailto:jd@commandprompt.com]
Sent: 21 April 2004 19:16
To: Jan Wieck
Cc: PostgreSQL-development
Subject: Re: [HACKERS] contrib vs. gborg/pgfoundry for
replication solutions

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.

Couldn't agree more.

Regards, Dave.

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

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" <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

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:

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 #

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

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:

IMHO it's not all that important where the source is developed (core
cvs, gborg etc) - whichever suits the development/release model best
shuold be used (meaning inside core only if it should be released on the
very same schedule as the main backend only).

What is more important is the exposure of the released versions. I think
it should be possible (and fairly easy) for projects developed outside
the core to get included in the "official download page", meaning go on
the ftp site and mirrors. Today it seems ODBC and pgadmin3 go there, but
pretty much nothing else (not even JDBC?). Perhaps a good structure
there would allow more proejcts to get that kind of exposure, and be
easier to find.

I quite often get people who claim "there is no this or that" for pgsql
when it's on gborg - simply becauase they didn't find it on the ftp
site. If you go looking, you'll find it on gborg, but if you don't know
where to look it can be hard. Especially for newcomers.

//Magnus

People:

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.

I agree with this. Although I point out that, per Jan, Slony does *not* fall
in this group.

From my perspective, there are 2 criteria for something being in Contrib:

1) is the module tightly tied to particular versions of PostgreSQL, so that
the version shipped with 7.4 would not work with 7.5 or with 7.3?

2) Is the module being considered for eventual incorporation into the
mainstream backend?

That being said, let us get projects.postgresql.org up and running first ...
we've hit some technical snags today.

--
-Josh Berkus
Aglio Database Solutions
San Francisco

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

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

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

On Thu, 22 Apr 2004, Magnus Hagander wrote:

IMHO it's not all that important where the source is developed (core
cvs, gborg etc) - whichever suits the development/release model best
shuold be used (meaning inside core only if it should be released on the
very same schedule as the main backend only).

What is more important is the exposure of the released versions. I think
it should be possible (and fairly easy) for projects developed outside
the core to get included in the "official download page", meaning go on
the ftp site and mirrors. Today it seems ODBC and pgadmin3 go there, but
pretty much nothing else (not even JDBC?). Perhaps a good structure
there would allow more proejcts to get that kind of exposure, and be
easier to find.

I see no reaosn why projects can't be mirrored into the main ftp server,
and brought through the mirrors ...

I quite often get people who claim "there is no this or that" for pgsql
when it's on gborg - simply becauase they didn't find it on the ftp
site. If you go looking, you'll find it on gborg, but if you don't know
where to look it can be hard. Especially for newcomers.

ftp://gborg.postgresql.org/pub - ls everything is listed there ...

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

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