Re: [pgsql-advocacy] Increased company involvement
От | Tom Lane |
---|---|
Тема | Re: [pgsql-advocacy] Increased company involvement |
Дата | |
Msg-id | 1096.1115061179@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [pgsql-advocacy] Increased company involvement ("Marc G. Fournier" <scrappy@postgresql.org>) |
Ответы |
Re: [pgsql-advocacy] Increased company involvement
|
Список | pgsql-hackers |
"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. regards, tom lane
В списке pgsql-hackers по дате отправления: