On Tue, 5 Apr 2005 06:01 am, Joshua D. Drake wrote:
> Tom Lane wrote:
>
> >Andrew Dunstan <andrew@dunslane.net> writes:
> >
> >>... If there are no license or build issues I'm in favor.
> >>
> >
> >Peter has pointed out that the problem of circular dependencies is a
> >showstopper for integrating plPHP. The build order has to be
> > Postgres
> > PHP (since its existing DB support requires Postgres to build)
> > plPHP
> >so putting #1 and #3 into the same package is a no go. Which is too
> >bad, but I see no good way around it.
> >
> O.k. I am confused here. You do not need PHP DB support for plPHP. You only
> need the php.so (once were done anyway). Which means that as long as PHP
> is installed it will work, just like plperl or plpython.
>
> The ONLY reason you would build PHP separately is if your stock installed
> PHP didn't have a feature enabled that you want. This has nothing at all
> to do with plPHP.
>
The issue also includes the fact that you can't install libpq without having postgresql
installed. If you could do that, the circular dependency wouldn't exist.
Some systems build postgresql into php, given that is the case, what Tom says is correct.
First you would have to force postgresql to be installed without pl/php. Then install php
with postgresql support, then install pl/php.
OR
Install php without postgresql support
Install postgresql with pl/php
Rebuild php with postgresql support (Unless you only want it available in the db)
I may be a bad man for suggesting it... But is it possible to ship libpq as a seperate
tarball that you can compile without postgresql server?
Regards
Russell Smith