Обсуждение: PL/php in pg_pltemplate
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 Herrera http://www.advogato.org/person/alvherre "Always assume the user will do much worse than the stupidest thing you can imagine." (Julien PUYDT)
> 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
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
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.
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/