Matteo Beccati wrote:
Hi Alvaro,
I've also seen there is an experimental embed sapi which could
already be what you need (--enable-embed).
Interesting. I'll explore this. Is this available in PHP5 only?
I found it while checking the available SAPIs in PHP4. Looking to the
cvs reposito
Hi Alvaro,
I've also seen there is an experimental embed sapi which could already
be what you need (--enable-embed).
Interesting. I'll explore this. Is this available in PHP5 only?
I found it while checking the available SAPIs in PHP4. Looking to the
cvs repository, it seems to be availab
Peter Eisentraut said:
> Andrew Dunstan wrote:
>> I'll be curious to see how we are going to have to manage a build
>> system like this with buildfarm - it sounds like it will make life
>> more complicated, but maybe it will work. Certainly it will make us
>> have to use more conditional logic.
>
>
Peter Eisentraut wrote:
Joshua D. Drake wrote:
Not only that, plphp does not require the building of php. It can
link directly to the .so file :)
Where do you get that from without having php built first?
From all the OS distributors.. On linux:
yum/apt install php php-devel :)
Joshua D.
Peter Eisentraut wrote:
> I'm more concerned about operating system builders, who will, in one
> way or another, have to build everything from scratch in a
> deterministic order.
This is not a problem with the PL/php I'm working on. (It appears to be
with the original PL/php -- I haven't checked
Andrew Dunstan wrote:
> I'll be curious to see how we are going to have to manage a build
> system like this with buildfarm - it sounds like it will make life
> more complicated, but maybe it will work. Certainly it will make us
> have to use more conditional logic.
This should not affect the buil
Andrew Dunstan wrote:
> Joshua D. Drake said:
> >
> >> The build order would be:
> >>
> >> 1. postgresql
> >> 2. php
> >> 3. plphp
> >>
> >> There is not circular build dependency there.
> >
> > Not only that, plphp does not require the building of php. It can link
> > directly to the .so file :)
>
Matteo Beccati wrote:
> >The only sore point of the PL/php build is that it needs the Apache2
> >module, so it needs to know the path to it. I haven't found a way to do
> >this automatically without requiring APXS which I certainly don't want
> >to do ...
>
> Maybe I didn't get the point, but th
Joshua D. Drake said:
>
>> The build order would be:
>>
>> 1. postgresql
>> 2. php
>> 3. plphp
>>
>> There is not circular build dependency there.
>
> Not only that, plphp does not require the building of php. It can link
> directly to the .so file :)
>
This makes no sense. Where do you get the .
Hi,
The only sore point of the PL/php build is that it needs the Apache2
module, so it needs to know the path to it. I haven't found a way to do
this automatically without requiring APXS which I certainly don't want
to do ...
Maybe I didn't get the point, but this could be as simple as writin
Joshua D. Drake wrote:
> Not only that, plphp does not require the building of php. It can
> link directly to the .so file :)
Where do you get that from without having php built first?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)
The build order would be:
1. postgresql
2. php
3. plphp
There is not circular build dependency there.
Not only that, plphp does not require the building of php. It can link
directly to the .so file :)
Sincerely,
Joshua D. Drake
---(end of broadcast)-
Andrew Dunstan wrote:
> I have no objection to this, but it's not clear to me that it buys much
> either. AFAIK only very modern PHP releases escape the circular dependency
> issue, no matter how we arrange our source code. What versions of PHP will
> PL/PHP be supporting?
Currently PL/php builds
Peter Eisentraut wrote:
> If you upgrade from PostgreSQL 8.0 to 8.1 you effectively also upgrade
> from "PL/pgSQL 8.0" to "PL/pgSQL 8.1". That's why we can and should
> and do alter the installation parameters of that language at the same
> time. But you don't necessarily upgrade from PL/foo
Andrew Dunstan wrote:
> I have no objection to this, but it's not clear to me that it buys
> much either. AFAIK only very modern PHP releases escape the circular
> dependency issue, no matter how we arrange our source code. What
> versions of PHP will PL/PHP be supporting?
The build order would be
Peter Eisentraut said:
> Joshua D. Drake wrote:
>> Unless I missed something PLphp will be able to be in core (once it is
>> all cleaned up). At least
>> that was the last consensus that I read. My understanding was that it
>> just wouldn't compile
>> by default?
>
> Well, either you missed somethi
Joshua D. Drake wrote:
> Unless I missed something PLphp will be able to be in core (once it
> is all cleaned up). At least
> that was the last consensus that I read. My understanding was that it
> just wouldn't compile
> by default?
Well, either you missed something or I missed something. :-)
Th
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > The counterargument has been that a PostgreSQL major version
> > upgrade would typically require a version upgrade of all language
> > handlers. In my experience of maintaining and observing the
> > maintenance of binary packages f
I just realized that this is the first out-of-core language for which
this has been proposed. I wonder why Joe Conway didn't submit an entry
for PL/R. (Is there any other language out there?)
Slightly off topic but:
Unless I missed something PLphp will be able to be in core (once it is
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> The counterargument has been that a PostgreSQL major version upgrade
> would typically require a version upgrade of all language handlers. In
> my experience of maintaining and observing the maintenance of binary
> packages for PostgreSQL and langu
Alvaro Herrera wrote:
> Well, it's one step less for installing the language. Users just
> install the library and issue the appropiate CREATE LANGUAGE call; no
> need to mess with specifying the handler/validator function name.
> (Which is not a very big deal, granted, but it's precisely the reas
Peter Eisentraut wrote:
> Tom Lane wrote:
> > I don't see any strong reason for enforcing that as policy, if the
> > language maintainer wants an entry. (But is Alvaro the maintainer of
> > pl/php?)
Yes, I have started work on PL/php and currently I'm the only
maintainer. I must add that the cod
Le Jeudi 24 Novembre 2005 18:07, Peter Eisentraut a écrit :
> Tom Lane wrote:
> > I don't see any strong reason for enforcing that as policy, if the
> > language maintainer wants an entry. (But is Alvaro the maintainer of
> > pl/php?) My recollection is that we identified some pros and cons of
>
Tom Lane wrote:
> I don't see any strong reason for enforcing that as policy, if the
> language maintainer wants an entry. (But is Alvaro the maintainer of
> pl/php?) My recollection is that we identified some pros and cons of
> having listings for non-core languages, and decided it should be up
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> Is anybody opposed to having PL/php in pg_pltemplate in the 8.1
>> branch? If not, I will add it on monday. (I plan to add it to 8.2 at
>> the same time.)
> pg_pltemplate should only be used for languages that are included in
Alvaro Herrera wrote:
> Is anybody opposed to having PL/php in pg_pltemplate in the 8.1
> branch? If not, I will add it on monday. (I plan to add it to 8.2 at
> the same time.)
pg_pltemplate should only be used for languages that are included in the
PostgreSQL source tree.
--
Peter Eisentraut
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> Is anybody opposed to having PL/php in pg_pltemplate in the 8.1 branch?
>> If not, I will add it on monday. (I plan to add it to 8.2 at the same
>> time.)
> With non-forced initdb?
It's too late to be making catalog changes in the 8.1 branch
Is anybody opposed to having PL/php in pg_pltemplate in the 8.1 branch?
If not, I will add it on monday. (I plan to add it to 8.2 at the same
time.)
With non-forced initdb?
Chris
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Hackers,
Is anybody opposed to having PL/php in pg_pltemplate in the 8.1 branch?
If not, I will add it on monday. (I plan to add it to 8.2 at the same
time.)
--
Alvaro Herrerahttp://www.advogato.org/person/alvherre
"Always assume the user will do much worse than the stup
29 matches
Mail list logo
