Marc G. Fournier wrote:
> On Mon, 2 May 2005, Bruce Momjian wrote:
>
> > Marc G. Fournier wrote:
> >> On Mon, 2 May 2005, Bruce Momjian wrote:
> >>
> >>> Marc G. Fournier wrote:
> >>>> On Mon, 2 May 2005, Bruce Momjian wrote:
> >>>>
> >>>>> I posted this compromise and no one replied so I thought everyone was OK
> >>>>> with it. It gets it into CVS, but has a separate compile stage to deal
> >>>>> with the recursive dependency problem.
> >>>>
> >>>> 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?
> >
> > The issue is that we have had to wack around the existing PL languages
> > for almost every release to make them work with server changes, and
> > being outside our CVS, plPHP isn't getting that whacking.
>
> And the point is, as Tom has pointed out with tsearch2, that even *in*
> CVS, it is a fair amount of work to 'whack' other ppls code ... it
> shouldn't be Tom's responsibility (which is generally what it comes down
> to) to keep someone else's code up to speed with changes in the server ...
When a PL languages is so tied to the changing API that it will only
work for a single major release of PostgreSQL, like ecpg, it is usually
kept in our CVS. This isn't true of odbc, jdbc, or other stuff, and not
even Slony.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
