Re: [pgsql-advocacy] Increased company involvement

Поиск
Список
Период
Сортировка
От Robert Treat
Тема Re: [pgsql-advocacy] Increased company involvement
Дата
Msg-id 200505041446.51856.xzilla@users.sourceforge.net
обсуждение исходный текст
Ответ на Re: [pgsql-advocacy] Increased company involvement  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Dann Corbit"
Дата:
Сообщение: Re: "Priority Mechanisms for OLTP and Transactional Web Applications"
Следующее
От: "Dann Corbit"
Дата:
Сообщение: FW: "Priority Mechanisms for OLTP and Transactional Web Applications"