Re: [pgsql-advocacy] Increased company involvement

From: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [pgsql-advocacy] Increased company involvement
Date: 2005-05-04 18:46:51
Message-ID: 200505041446.51856.xzilla@users.sourceforge.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-hackers

On Monday 02 May 2005 15:12, Tom Lane wrote:
> "Marc G. Fournier" <scrappy(at)postgresql(dot)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

In response to

Browse pgsql-advocacy by date

  From Date Subject
Next Message Josh Berkus 2005-05-04 20:30:41 "Enterprise User" wanted
Previous Message Mitch Pirtle 2005-05-04 18:21:10 Re: [OT] Re: [HACKERS] Increased company involvement

Browse pgsql-hackers by date

  From Date Subject
Next Message Dann Corbit 2005-05-04 19:50:05 FW: "Priority Mechanisms for OLTP and Transactional Web Applications"
Previous Message Dann Corbit 2005-05-04 18:43:02 Re: "Priority Mechanisms for OLTP and Transactional Web Applications"