PL/php in pg_pltemplate

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

Christopher Kings-Lynne <chriskl@familyhealth.com.au> 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, unless
for really critical bugs, which this surely isn't.

regards, tom lane

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
http://developer.postgresql.org/~petere/

Peter Eisentraut <peter_e@gmx.net> 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 the
PostgreSQL source tree.

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 to
the language maintainers to decide what they want.

regards, tom lane

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
to the language maintainers to decide what they want.

Perhaps Alvaro can identify the reasons why he wants this done and then
we can determine whether it's a good idea.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

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
having listings for non-core languages, and decided it should be up
to the language maintainers to decide what they want.

Perhaps Alvaro can identify the reasons why he wants this done and then
we can determine whether it's a good idea.

Hi, I am not a postgresql expert but there is one thing I think important
about adding language into core postgresql:

each time you'll add a new features needing external libraries into core
package, this mean the guy building postgresql should have devellopment files
for of the library installed at postgresql compil time.

For exemple, on pgfoundry you can found pgrpm (rpm binding for postgres), this
kind of thing have nothing to do into postgresql core package IMHO, because
to be built it need rpm to be installed, most of system doesn't have rpm.

It is same things for language, is it a good to have perl, tcl, python, php,
ruby, lua, basic, lisp (add other crazy idea here :) provided by postgresql
itself ? I don't know what language I will use tomorrow, but I know I am
already using postgres.

Wouldn't be better, like for pgrpm, to provide this kind of things as external
project/plugins that can be build and installed later ?

But you surelly have a better point of view of this than me.

BTW, In mandriva, since postgresql 8.0, there is one rpm per language to avoid
dependencies flow, so you need to install language lib only if you install
PL/language .so files.

My 2 cents, hope this help.

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 code is far from ready yet, but I
expect that by the time 8.2 comes around it will be in much better
shape. (To the point that it doesn't take a single-line function to
crash the server, for example.)

My recollection is that we identified some pros and cons of
having listings for non-core languages, and decided it should be up
to the language maintainers to decide what they want.

Perhaps Alvaro can identify the reasons why he wants this done and then
we can determine whether it's a good idea.

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 reason
why pg_pltemplate was invented.)

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?)

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

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 reason
why pg_pltemplate was invented.)

No, the actual reason why pg_pltemplate was invented is so that during a
major version upgrade, the CREATE LANGUAGE statement contained in the
dump would automatically be readjusted internally to pick up whatever
new features the language would provide in the new major version (e.g.,
a new validator function). The applicability of that feature, in my
heavily contested opinion mind you, to non-core languages is reduced by
two facts:

1. A major version upgrade does not entail an upgrade of the respective
language handler, both because of mere software availability and
because of a possible upgrade-only-one-thing-at-a-time policy.

2. The PostgreSQL backend is not in an authoritative position to know
what kind of features a certain external language handler really
provides (think development versions, for example).

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 languages, this is decidedly false, at
least in the general case.

The PL/PHP package is a pretty obvious case where things can go wrong,
especially if you have tight dependencies. You may decide that the
next version of PL/PHP will require PHP 5.2.0. You put that in the
pltemplate for PostgreSQL 8.2. When someone packages that for some
Linux distribution, that distribution may not have PHP 5.2.0 ready
because of the insanse dependency chains that PHP brings in. So they
have to stick to the old PL/PHP in their distribution, but PostgreSQL
8.2 does not know that. So either PL/PHP is broken or they have to
patch the source code (well, the system catalogs) of PostgreSQL. You
can see, the more languages we bring in this way, the farther the
dependency chaos reaches. And I don't think that's worth saving some
typing...

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut <peter_e@gmx.net> 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 languages, this is decidedly false, at
least in the general case.

Really? I'd argue the opposite. See also the recent proposal to
*force* recompilation of all loadable shared libraries for every
major PG version, by means of embedding a version number in them.
If you think that would be a bad idea you'd better weigh in on that
thread pretty soon ...

The PL/PHP package is a pretty obvious case where things can go wrong,
especially if you have tight dependencies. You may decide that the
next version of PL/PHP will require PHP 5.2.0. You put that in the
pltemplate for PostgreSQL 8.2.

Hm? Where in pltemplate is there any knowledge of PHP versions?

regards, tom lane

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
all cleaned up). At least
that was the last consensus that I read. My understanding was that it
just wouldn't compile
by default?

Sincerely,

Joshua D. Drake

--
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: PLphp, PLperl - http://www.commandprompt.com/

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> 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 languages, this
is decidedly false, at least in the general case.

Really? I'd argue the opposite. See also the recent proposal to
*force* recompilation of all loadable shared libraries for every
major PG version, by means of embedding a version number in them.

That's a recompilation of the *same* version, not an upgrade of the
version of the PL.

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 0.77 to PL/foo
0.78 at that time (instead you just recompile 0.77), which is why we
cannot really randomly include information on PL/foo in pltemplate
unless we make very particular arrangements with that development team,
which I don't see being done in any proposed case.

The PL/PHP package is a pretty obvious case where things can go
wrong, especially if you have tight dependencies. You may decide
that the next version of PL/PHP will require PHP 5.2.0. You put
that in the pltemplate for PostgreSQL 8.2.

Hm? Where in pltemplate is there any knowledge of PHP versions?

pltemplate would more or less contain a hidden versioned dependency on
the external language. (pltemplate says, "The last known version of
PL/foo at the time of release supports these features." and you need to
use at least that version or the language installation might be
broken.) So we'd pull in a versioned dependency on PL/PHP, which might
have a versioned dependency on PHP (which might have a versioned
dependency on libssl, which is incompatible with the one used by
PostgreSQL, or whatever other weird case you want to imagine).

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

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. :-)

The last proposal I heard was that we move all core languages a bit
farther away from the core and then add hitherto-non-core languages at
that same level. This would possibly mean that these languages become
their own CVS module but in the same CVS tree, and we'd release them
all at the same time as the server release but in separate source
packages. This will resolve all concerns about bit/interface rot,
circular build dependencies, and you'd get no more objection from me
about pltemplate.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

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 something or I missed something. :-)

The last proposal I heard was that we move all core languages a bit
farther away from the core and then add hitherto-non-core languages at
that same level. This would possibly mean that these languages become
their own CVS module but in the same CVS tree, and we'd release them
all at the same time as the server release but in separate source
packages. This will resolve all concerns about bit/interface rot,
circular build dependencies, and you'd get no more objection from me
about pltemplate.

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?

cheers

andrew

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:

1. postgresql
2. php
3. plphp

There is not circular build dependency there.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

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 0.77 to PL/foo
0.78 at that time (instead you just recompile 0.77), which is why we
cannot really randomly include information on PL/foo in pltemplate
unless we make very particular arrangements with that development team,
which I don't see being done in any proposed case.

Well, since I'm the development team of PL/php, I can make arrangements
with myself that the information on pg_pltemplate about PL/php is
correct :-) In particular, PL/php provides a call handler called
"plphp_call_handler" and a validator called plphp_validator.

In general, the validator may be a stub, which means that if a
particular PL team does not have a validator but wants to build one
eventually, then they provide a function that does nothing. This is not
a particularly hard requisite to fulfill. (In the particular case of
PL/php, we already provide a non-stub validator so this point is moot.)

(Oh, also note that the previous version of PL/php is so hard to install
and so generally broken, that I wouldn't even worry about it not
providing the necessary validator function. In practice you do need the
as-of-yet unreleased PL/php 1.1 to do any serious work anyway.)

pltemplate would more or less contain a hidden versioned dependency on
the external language. (pltemplate says, "The last known version of
PL/foo at the time of release supports these features." and you need to
use at least that version or the language installation might be
broken.)

Well, currently the group of features is a function handler and a
validator. It's easy to fulfill both; the former, because if there
isn't a call handler then there isn't PL in the first place. The
latter, because you can provide an empty function. If we expand the
catalog in the future, we can talk about what should we fill the entries
with at that time.

There is no other requirement imposed by pltemplate. You need to have
no special symbols or whatever.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

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 using PGXS so you don't need to build it with
the rest of PostgreSQL. This means no circular dependency involved.
AFAICS PL/Perl could do the same just as well, probably PL/Python and
PL/Tcl could too.

(I'm using PHP 4.4.1 to develop. AFAIK it works just as well with PHP
5, but I haven't tried yet.)

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 ...

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

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

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/

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 writing a
new PHP sapi (i.e. sapi/pgsql) which builds the .so without requiring
Apache or other software.

I've also seen there is an experimental embed sapi which could already
be what you need (--enable-embed).

Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com

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 this could be as simple as writing a
new PHP sapi (i.e. sapi/pgsql) which builds the .so without requiring
Apache or other software.

Yeah, I've considered doing that; but PHP/Zend code is so ugly that I'd
want to stay as far away from it as possible. In the end, it's likely
that I'll need to write a whole new SAPI anyway. (Really the current
PL/php code is a sort of replacement for part of the Apache2 SAPI, so
maybe we're not that far from a complete SAPI.)

Oh, and the problem with building a new SAPI is that I'll need to have
PHP built in order to be able to install PL/php, so it's not as sexy as
just using the Apache2 SAPI which is very ubiquitous.

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?

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

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 :)

This makes no sense. Where do you get the .so file and the headers you will
undoubtedly also need?

Why, you use the distributor's package of course ;-) The fact is you
don't need to _rebuild_ PHP.

Also, having to put php in the middle of this sequence is ugly, to say the
least.

Well, it's already that way, to build PHP's Postgres driver. But this
is in no way related to PL/php.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

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 .so file and the headers you will
undoubtedly also need?

Also, having to put php in the middle of this sequence is ugly, to say the
least.

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.

cheers

andrew

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 build farm. You'd just use the operating
system's PHP package. 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.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

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, and I didn't ever build
it in the first place because the build system seemed so dumb that it
was the first thing I rewrote.)

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

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. Drake

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.

This should not affect the build farm. You'd just use the operating
system's PHP package. 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.

Well, yes, that concerns me too. But I also want to know what the build
process will look like? Will there be separate configure scripts, for
instance?
cheers

andrew

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 available since PHP 4.3.0:

http://cvs.php.net/php-src/sapi/embed/php_embed.c

Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com

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 repository, it seems to be available since PHP 4.3.0:

http://cvs.php.net/php-src/sapi/embed/php_embed.c

I am o.k. with supporting 4.3 and above only.

Joshua D. Drake

Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com

--
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: PLphp, PLperl - http://www.commandprompt.com/