The reasoning behind having several features outside of source?

#11

On Sat, 30 Oct 2004 nd02tsk (AT) student (DOT) hig.se wrote:

Quote:

Jeff Davis wrote:

Other people have answered, but I'd like to add:

It makes it much faster to fix bugs and improve features in the projects
outside of the source tree. If replication has a bug, you don't want to
wait for the next point release, you want a fix *now*. PostgreSQL is a
big project, and can't make new point releases every time a bug appears
in a small subsystem.

Replication is one subsystem not included in source tree. But PostgreSQL
has other subsystems that are included such as plugins for procedural
languages. So isn't the same risks involved with them?

Yes, which is why you will find that several of them are 'outside
projects' for development purposes ... in fact, if you looked back at the
earlier 7.x series, you will find that they had more interfaces then the
current code does ... alot has been moved out over the years. libpq++ is
a prime example of something that had official status for the longest
time, but where someone came along and wrote a 'better' version of it,
which is now on gborg ...

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

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

#12

On Sat, 30 Oct 2004, Joshua D. Drake wrote:

Quote:

Replication is one subsystem not included in source tree. But PostgreSQL
has other subsystems that are included such as plugins for procedural
languages. So isn't the same risks involved with them?

No, not really. Because items such as plPerl don't require
changes to the backend. Replication requires changes to the backend.

Replication doesn't require changes to the backend ... neither eRServer or
Slony-I do, at least ...

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

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org

#13

On Sat, Oct 30, 2004 at 04:39:42PM -0300, Marc G. Fournier wrote:

Quote:

On Sat, 30 Oct 2004, Joshua D. Drake wrote:

No, not really. Because items such as plPerl don't require
changes to the backend. Replication requires changes to the backend.

Replication doesn't require changes to the backend ... neither eRServer or
Slony-I do, at least ...

But both Slony-II and the CMD replication solution do ...

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"No reniegues de lo que alguna vez creíste"

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

#14

"Marc G. Fournier" <scrappy (AT) postgresql (DOT) org> writes:

Quote:

On Sat, 30 Oct 2004 nd02tsk (AT) student (DOT) hig.se wrote:
Replication is one subsystem not included in source tree. But PostgreSQL
has other subsystems that are included such as plugins for procedural
languages. So isn't the same risks involved with them?

Yes, which is why you will find that several of them are 'outside
projects' for development purposes ...

We have been trying to "push out" anything that is not fairly tightly
tied to the core backend, enough so that it's easier to maintain with
the backend than separately. The PL languages are in a gray area, but
for the most part it seems better to treat them as part of the core for
maintenance purposes. They tend to need fixed whenever we make any
changes to internal backend APIs. (See for instance discussion just now
in pghackers with Thomas Hallgren --- if PL/Java had been part of the
core distro then he'd not now be playing catchup to make it work with
8.0 CVS tip...)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

#15

On 10/30/2004 3:39 PM, Marc G. Fournier wrote:

Quote:

On Sat, 30 Oct 2004, Joshua D. Drake wrote:

Replication is one subsystem not included in source tree. But PostgreSQL
has other subsystems that are included such as plugins for procedural
languages. So isn't the same risks involved with them?

No, not really. Because items such as plPerl don't require
changes to the backend. Replication requires changes to the backend.

Replication doesn't require changes to the backend ... neither eRServer or
Slony-I do, at least ...

Slony-II will probably need some additional features. But I consider it
a sign for an immature design not to be able to define those features in
form of an API and instead starting to hack together a prototype inside
of the backend that later down the road will get promoted to a solution
because there never will be any time to turn the findings of that
explore-phase into a design and develop according to that.

Jan

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

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

The reasoning behind having several features outside of source?

comp.databases.postgresql.general comp.databases.postgresql.general

Re: The reasoning behind having several features outside - 10-30-2004 , 02:15 PM

Re: The reasoning behind having several features outside - 10-30-2004 , 02:39 PM

Re: The reasoning behind having several features outside - 10-30-2004 , 03:05 PM

Re: The reasoning behind having several features outside - 10-30-2004 , 03:07 PM

Re: The reasoning behind having several features outside - 10-30-2004 , 03:15 PM