Re: [pgsql-advocacy] Increased company involvement - Mailing list pgsql-hackers

From Robert Treat
Subject Re: [pgsql-advocacy] Increased company involvement
Date
Msg-id 200505041446.51856.xzilla@users.sourceforge.net
Whole thread Raw
In response to Re: [pgsql-advocacy] Increased company involvement  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Monday 02 May 2005 15:12, Tom Lane wrote:
> "Marc G. Fournier" <scrappy@postgresql.org> writes:
> > On Mon, 2 May 2005, Bruce Momjian wrote:
> >> Marc G. Fournier wrote:
> >>> Then what is the point of having it in CVS?  Other then to make are tar
> >>> ball bigger?
> >>
> >> So it can be maintained with other PL languages as the internal API
> >> changes.  This is the same reason ecpg is in our CVS because it is tied
> >> to the grammar.
> >
> > Since when?  I thought you didn't need the PostgreSQL sources in order to
> > compile pl/PHP, only the installed headers/libraries ... Joshua, has
> > something changed, or did I mis-understand that requirement?
>
> That could be said of *any* of our PLs (at least now that we install all
> server-side headers by default ;-)).  I think the real reason we keep
> pltcl etc in the core CVS is exactly what Bruce said: it's easier to
> maintain 'em that way.  The problem is that the PLs use all sorts of
> internal backend APIs that we don't want to freeze, and so they are
> constantly being affected by changes in the core backend.  Just look
> at the CVS logs for evidence.
>
> Personally, I'm willing to fix the PLs whenever I make a change that
> affects them, but only if they're in core CVS.  Dealing with parallel
> changes in two different code repositories is too much of a pain.
> So the folks maintaining non-core PLs take a big hit every release when
> they have to sync with what's happened in the core backend meanwhile.
>

Somewhere I think OS independence is a factor here.  Things in the core distro 
can generally be figured to work on multiple platforms, especially if the are 
getting put through some compiling via the buildfarm.  Code on pgfoundry is 
probably less likely to work on multiple OS's simply because they may not 
have the developer eyeballs to spare for extra platforms.  On some projects 
like slony this is probably fine, as you can wait for intrest to spring up 
before needing to do some work, however other things like odbc or maybe 
libpqxx are things that we really do want to be able to work on all our 
supported platforms, and having them outside core hurts thier chances. 

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


pgsql-hackers by date:

Previous
From: "Dann Corbit"
Date:
Subject: Re: "Priority Mechanisms for OLTP and Transactional Web Applications"
Next
From: "Dann Corbit"
Date:
Subject: FW: "Priority Mechanisms for OLTP and Transactional Web Applications"