Re: [GENERAL] [HACKERS] plPHP in core?
On Tue, 5 Apr 2005 06:01 am, Joshua D. Drake wrote: Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] [HACKERS] plPHP in core?
On Tue, Apr 05, 2005 at 06:06:09PM +1000, Russell Smith wrote: 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) Take for example Debian, it autobuilds any source package on 11 architectures or so. The rule is, install dependancies, build source. It has to be reproducable. You can't build twice and get different results. Yes, if you're building it yourself you can do all sorts of trick, but autobuilders can't. Circular dependancies are a no-no. 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? I guess that seperate tarball would have to include pg_dump, pg_ctl and any of the other included programs that depend on libpq. Seperating server and client portions is an interesting idea. Ofcourse, the regression tests would become a third package and then you could spend time making them all match. I suppose the choice comes down to either PHP splitting the DB access (like other languages) or PostgreSQL splitting out pl/PHP. -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. pgpOGoSh5FUYe.pgp Description: PGP signature
Re: [GENERAL] [HACKERS] plPHP in core?
Greg Sabino Mullane said: Other languages don't require PG to be installed in order to compile them. For example, you can build Perl (with no Postgres on the system), build Postgres and then build DBD::Pg as a completely separate step. Just so we are all on the same sheet of music, DBD::Pg is a completely different animal from Pl/Perl I think everybody gets that. and really has nothing to do with the discussion of adding Pl/PHP to the core. It's relevant because it's the *client* side support in PHP that creates a build dependency of PHP on Postgres. As was being pointed out above, Perl doesn't suffer from this defect. cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] [HACKERS] plPHP in core?
El Lun 04 Abr 2005 17:36, Tom Lane escribió: Joshua D. Drake [EMAIL PROTECTED] writes: Maybe I am just dense, but the argument seems to be completely moot. PHP is no different than Perl or Python in this case. Perl and Python don't have BuildPrereq: postgresql-devel in their rpmspecs. PHP does. The header files would not be a problem. The real problem is that you also need to have postgresql-libs. :-( Any way, RH deals all the times with circular dependencies. P.D.: It would be nice to have plPHP in the core, IMHO. -- 09:03:26 up 3 days, 17:32, 1 user, load average: 0.39, 0.61, 0.64 - Martín Marqués| select 'mmarques' || '@' || 'unl.edu.ar' Centro de Telematica | DBA, Programador, Administrador Universidad Nacional del Litoral - ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] [HACKERS] plPHP in core?
El Lun 04 Abr 2005 18:00, Doug McNaught escribió: Robert Treat [EMAIL PROTECTED] writes: If by stripped down you mean without postgresql database support then I'll grant you that, but it is no different than other any other pl whose parent language requires postgresql to be installed. If packagers are able to handle those languages than why can't they do the same with PHP ? Other languages don't require PG to be installed in order to compile them. For example, you can build Perl (with no Postgres on the system), build Postgres and then build DBD::Pg as a completely separate step. The same thing can be done with PHP. -- 09:25:38 up 3 days, 17:54, 1 user, load average: 0.45, 0.28, 0.38 - Martín Marqués| select 'mmarques' || '@' || 'unl.edu.ar' Centro de Telematica | DBA, Programador, Administrador Universidad Nacional del Litoral - ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] [HACKERS] plPHP in core?
=?iso-8859-1?q?Mart=EDn_Marqu=E9s?= martin@bugs.unl.edu.ar writes: El Lun 04 Abr 2005 17:36, Tom Lane escribió: Perl and Python don't have BuildPrereq: postgresql-devel in their rpmspecs. PHP does. The header files would not be a problem. The real problem is that you also need to have postgresql-libs. :-( Actually the header files are a problem too, because you can't have 'em without doing at least a configure to generate the machine-specific ones. The configure would already fail if PHP weren't installed and --with-php were mentioned. So the process would have to look something like -- configure PG, but lie about your ultimate intentions -- install bogus PG header files -- build and install PHP -- reconfigure PG, and hope you don't mess up by changing anything except the --with-php flag -- build and install PG This is just not reasonable from a packaging standpoint. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] [HACKERS] plPHP in core?
On Tue, 5 Apr 2005, Russell Smith wrote: 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? Actually, its something that I'm going to sit down and work on ... not pulling libpq out of core, but creating a 'dist' target to makes a tar ball that includes everything required to build it seperately ... its a matter of finding the time to do it :( Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] [HACKERS] plPHP in core?
Honestly, I think if we're going to spend time worrying about languages as features then we should be doing more to advertise the fact that perl/PHP/python/ruby/etc programmers can program in the database in their native language. I agree with you completely. This is something that makes PostgreSQL unique and should provide additional incentive for people to use PostgreSQL. I don't think it matters much at all if those 'bonus languages' are included in core or not, at least not to end-users. -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL begin:vcard fn:Joshua Drake n:Drake;Joshua org:Command Prompt, Inc. adr:;;PO Box 215 ;Cascade Locks;OR;97014;US email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0334 x-mozilla-html:FALSE url:http://www.commandprompt.com version:2.1 end:vcard ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] [HACKERS] plPHP in core?
Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: On Fri, 1 Apr 2005, Joshua D. Drake wrote: Are we interested in having plPHP in core? Is there a reason why it can no longer operate as a standalone language out of pgfoundry, like pl/java and pl/perl? I have said this before. Let me say it again and please take note. I did not start the plperlng project on pgfoundry as an alternative to the core plperl. It is a developers sandbox, and it was always the intention to feed the work back to the core, as indeed we did for the 8.0 release. Frankly, if I had thought that there would be so much wilful misunderstanding of the intention I would not have done it. So please stop with this assertion that plperl runs from pgfoundry. I am really at a loss to understand thie push to get PLs out of the core. Whose interest do you think it will serve? We just advertised the upgrade to plperl as a major selling point of the 8.0 release. The someone might do it differently or better argument is a cop-out. If you're in the management group your responsibility is to make sensible choices. Lots of software acquires standard packages over time. Example: perl, which has an extremely well publicised and well-known extension system (CPAN) that has had for years a high resolution timer extension package available. From the 5.8 release that package has become part of the standard distribution. That doesn't stop anyone from developing a better or alternative hires timer. If we had a very much larger postgres development community then it might make sense to foster some diversity among PL implementations. We don't, so it doesn't, IMNSHO. PLs are sufficiently tightly tied to the core that it's probably easier to maintain them as part of our core CVS than otherwise. (Ask Joe Conway about PL/R. Thomas Hallgren is probably not that happy about maintaining pl/java out of core, either. And pl/perl *is* in core.) And we need the core support. I appreciate having the support and help of Tom, Joe, Bruce and others. I have little doubt Joshua Drake feels the same way. I'm thinking that a pl/PHP is much more interesting for the long term than, say, pl/tcl (mind you, I am a Tcl partisan from way back, but I see that many people are not so enlightened). Barring any licensing problems I think this is something to pursue. Yes, I regard it as an abomination unto man and god, but others want it. :-) If there are no license or build issues I'm in favor. Quite apart from anything else it might help grab some market share from all those apps built on php+mysql One last thing: one of the enhancements in the wind for buildfarm is to run the PL tests. This will *only* be done for PLs that are in the core - I am not going to get into buildfarm having to run cvs update against more than one source. So if you want that to happen, keep the PLs where they are (and take on pl/php if possible). I'd also love to have pl/ruby - is that another one that is inhibited by license issues? cheers andrew ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] [HACKERS] plPHP in core?
Andrew Dunstan [EMAIL PROTECTED] 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. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] [HACKERS] plPHP in core?
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] 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. Oh. I didn't see that - I assumed that it had been fixed. (My email has been AWOL for 48 hours). cheers andrew ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] [HACKERS] plPHP in core?
On Monday 04 April 2005 12:01, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] 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.
AFAICT Peter's claim is false. You can install plphp in the order of PHP,
PostgreSQL,plPHP which is the same for all of the other pl's.
You don't need postgresql installed before php any more than you need it
installed for perl (although you do need postgresql installed to compile some
of the perl php db interfaces, but that is all after the fact.)
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] [HACKERS] plPHP in core?
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] 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. Sincerely, Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] [HACKERS] plPHP in core?
Robert Treat [EMAIL PROTECTED] writes: On Monday 04 April 2005 12:01, Tom Lane wrote: Peter has pointed out that the problem of circular dependencies is a showstopper for integrating plPHP. AFAICT Peter's claim is false. You can install plphp in the order of PHP, PostgreSQL,plPHP which is the same for all of the other pl's. This is not an install problem, it is a build problem. PHP cannot be built (except in a stripped-down form) without Postgres already built. If we try to build plPHP as part of the Postgres package then we have the same problem in the other direction. We are going to be very unloved by packagers if we try to force them to deal with that (and remember I work for Red Hat nowadays ... in fact it would be *me* having to deal with the fallout from circular build dependencies). regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] [HACKERS] plPHP in core?
Robert Treat wrote: On Monday 04 April 2005 12:01, Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] 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. AFAICT Peter's claim is false. You can install plphp in the order of PHP, PostgreSQL,plPHP which is the same for all of the other pl's. You don't need postgresql installed before php any more than you need it installed for perl (although you do need postgresql installed to compile some of the perl php db interfaces, but that is all after the fact.) I am told that the difference is that PHP gives you a choice of statically or dynamically linked db support. By contrast, in Perl, for example, DBD::Pg is always built dynamically (AFAIK). Your assessment appears to be true for the (very common) case where PHP's client side db support is dynamically linked. cheers andrew ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] [HACKERS] plPHP in core?
Joshua D. Drake [EMAIL PROTECTED] writes: Maybe I am just dense, but the argument seems to be completely moot. PHP is no different than Perl or Python in this case. Perl and Python don't have BuildPrereq: postgresql-devel in their rpmspecs. PHP does. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] [HACKERS] plPHP in core?
I am told that the difference is that PHP gives you a choice of statically or dynamically linked db support. By contrast, in Perl, for example, DBD::Pg is always built dynamically (AFAIK). Your assessment appears to be true for the (very common) case where PHP's client side db support is dynamically lnked. PHP is typically dynamically built as well now. If you install redhat you have to explictly say php-pgsql to get postgresql support. This is the same on all the major Linux distriubtions I know of including one offs like Ubuntu. As Marc pointed out it is also the same on FreeBSD. Maybe I am just dense, but the argument seems to be completely moot. PHP is no different than Perl or Python in this case. Heck even if PHP is built statically (where the PostgreSQL driver is linked in versus an .so) it still has nothing to do with plPHP. Sincerely, Joshua D. Drake cheers andrew ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] [HACKERS] plPHP in core?
On Mon, 2005-04-04 at 16:17, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
On Monday 04 April 2005 12:01, Tom Lane wrote:
Peter has pointed out that the problem of circular dependencies is a
showstopper for integrating plPHP.
AFAICT Peter's claim is false. You can install plphp in the order of PHP,
PostgreSQL,plPHP which is the same for all of the other pl's.
This is not an install problem, it is a build problem. PHP cannot be
built (except in a stripped-down form) without Postgres already built.
If we try to build plPHP as part of the Postgres package then we have
the same problem in the other direction. We are going to be very
unloved by packagers if we try to force them to deal with that
(and remember I work for Red Hat nowadays ... in fact it would be *me*
having to deal with the fallout from circular build dependencies).
If by stripped down you mean without postgresql database support then
I'll grant you that, but it is no different than other any other pl
whose parent language requires postgresql to be installed. If packagers
are able to handle those languages than why can't they do the same with
PHP ?
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [GENERAL] [HACKERS] plPHP in core?
Robert Treat [EMAIL PROTECTED] writes: If by stripped down you mean without postgresql database support then I'll grant you that, but it is no different than other any other pl whose parent language requires postgresql to be installed. If packagers are able to handle those languages than why can't they do the same with PHP ? Other languages don't require PG to be installed in order to compile them. For example, you can build Perl (with no Postgres on the system), build Postgres and then build DBD::Pg as a completely separate step. -Doug ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] [HACKERS] plPHP in core?
On Mon, Apr 04, 2005 at 04:48:50PM -0400, Robert Treat wrote: If by stripped down you mean without postgresql database support then I'll grant you that, but it is no different than other any other pl whose parent language requires postgresql to be installed. If packagers are able to handle those languages than why can't they do the same with PHP ? Because those other languages are well designed and PHP is not. The Postgres support package for Perl is a completely separate add-on, which you can add well after the core of Perl is installed. Same for Python. But PHP is a braindead package which includes the Postgres support in the main codebase. The problem is that even if you could build a Postgres support package for PHP without building the whole PHP (which you _can_ do AFAIK), it means that you need to make a second pass at the PHP source RPM, which will be probably rejected by packagers. I think the problem could be solved if we were to include PHP in the main CVS, but not distribute it in the same tarball. So the code is kept where it really belongs, and we allow building both things separately for the packagers' sake. -- Alvaro Herrera ([EMAIL PROTECTED]) If it wasn't for my companion, I believe I'd be having the time of my life (John Dunbar) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] [HACKERS] plPHP in core?
Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Maybe I am just dense, but the argument seems to be completely moot. PHP is no different than Perl or Python in this case. Perl and Python don't have BuildPrereq: postgresql-devel in their rpmspecs. PHP does. That makes perfect sense. Although that req is usually a flag that can be turned on/off and the req is used to create the php-pgsql package. Although it sources from PHP of course. O.k. I see the other side of the argument thanks to Tom and Andrew, I don't agree with it (in terms of being an issue) but at least I understand it. Besides people could always choose to NOT package with plPHP regardless if it was in core. It would however be there for people who compile from a tar ball or for people who don't use PHP but do use plPHP (for whatever reason). Sincerely, Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] [HACKERS] plPHP in core?
On Mon, 2005-04-04 at 17:03, Alvaro Herrera wrote:
On Mon, Apr 04, 2005 at 04:48:50PM -0400, Robert Treat wrote:
If by stripped down you mean without postgresql database support then
I'll grant you that, but it is no different than other any other pl
whose parent language requires postgresql to be installed. If packagers
are able to handle those languages than why can't they do the same with
PHP ?
Because those other languages are well designed and PHP is not. The
Postgres support package for Perl is a completely separate add-on, which
you can add well after the core of Perl is installed. Same for Python.
But PHP is a braindead package which includes the Postgres support in
the main codebase.
The problem is that even if you could build a Postgres support package
for PHP without building the whole PHP (which you _can_ do AFAIK), it
means that you need to make a second pass at the PHP source RPM, which
will be probably rejected by packagers.
ISTM this is a problem with the packaging as much as it is with PHP, but
in neither case is this a problem for PostgreSQL. ISTM decisions as to
what is included in PostgreSQL core should not be based on the design
decisions of one vendors packaging scheme IMHO.
I think the problem could be solved if we were to include PHP in the
main CVS, but not distribute it in the same tarball. So the code is
kept where it really belongs, and we allow building both things
separately for the packagers' sake.
--
Alvaro Herrera ([EMAIL PROTECTED])
If it wasn't for my companion, I believe I'd be having
the time of my life (John Dunbar)
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [GENERAL] [HACKERS] plPHP in core?
On Mon, 2005-04-04 at 17:00, Doug McNaught wrote:
Robert Treat [EMAIL PROTECTED] writes:
If by stripped down you mean without postgresql database support then
I'll grant you that, but it is no different than other any other pl
whose parent language requires postgresql to be installed. If packagers
are able to handle those languages than why can't they do the same with
PHP ?
Other languages don't require PG to be installed in order to compile
them. For example, you can build Perl (with no Postgres on the
system), build Postgres and then build DBD::Pg as a completely
separate step.
You can build PHP (with no postgres on the system) and then build
Postgres and then build enable the php pgsql.so in a separate step as
well.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: [GENERAL] [HACKERS] plPHP in core?
Alvaro Herrera wrote: On Mon, Apr 04, 2005 at 04:48:50PM -0400, Robert Treat wrote: The problem is that even if you could build a Postgres support package for PHP without building the whole PHP (which you _can_ do AFAIK), it means that you need to make a second pass at the PHP source RPM, which will be probably rejected by packagers. FYI this is supposedly fixed in 5.1. Sincerely, Joshua D. Drake I think the problem could be solved if we were to include PHP in the main CVS, but not distribute it in the same tarball. So the code is kept where it really belongs, and we allow building both things separately for the packagers' sake. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] [HACKERS] plPHP in core?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Other languages don't require PG to be installed in order to compile them. For example, you can build Perl (with no Postgres on the system), build Postgres and then build DBD::Pg as a completely separate step. Just so we are all on the same sheet of music, DBD::Pg is a completely different animal from Pl/Perl and really has nothing to do with the discussion of adding Pl/PHP to the core. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200504042245 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iD8DBQFCUfwAvJuQZxSWSsgRAiyMAJ9S+02lvFdlOzZphOZDwaPrDboH/gCcCDlY xvPxk6f579EvQO3dxTaRreg= =FHfy -END PGP SIGNATURE- ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] [HACKERS] plPHP in core?
Alvaro Herrera [EMAIL PROTECTED] writes: Because those other languages are well designed and PHP is not. The Postgres support package for Perl is a completely separate add-on, which you can add well after the core of Perl is installed. Same for Python. But PHP is a braindead package which includes the Postgres support in the main codebase. Oh egads. I finally understand this whole thread. You guys are all talking about the old-fashioned Postgres support that has special pg* functions that deal only with Postgres. There are PHP modules that abstract that all away now, much like DBD::Pg, and I believe they can be build as external modules. So I'm not sure how much this matters any more. Perhaps it's still a factor for another release or two though. I'm surprised Tom's concerned about this. It's especially not relevant for distribution based systems like Debian or Redhat. There are tons of circular build dependencies in a complete distribution (think of the compiler toolchain for example) and packagers can just download binary packages for the packages they aren't developing at the time. -- greg ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] [HACKERS] plPHP in core?
On Sat, Apr 02, 2005 at 07:29:02AM -0800, Joshua D. Drake wrote: This argument doesn't hold too much weight. Namely because there are only 3-5 really popular languages out there. They are marketing languages. The are languages you include because your database doesn't sound complete with out them. Regardless if you can download them separately. People are lazy. They don't want to download them separately. I see those as: plPgsql (for Oracle people) plPerl plPHP What databases support perl or php stored procs/functions? Or python for that matter? -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] [HACKERS] plPHP in core?
Jim C. Nasby wrote: On Sat, Apr 02, 2005 at 07:29:02AM -0800, Joshua D. Drake wrote: This argument doesn't hold too much weight. Namely because there are only 3-5 really popular languages out there. They are marketing languages. The are languages you include because your database doesn't sound complete with out them. Regardless if you can download them separately. People are lazy. They don't want to download them separately. I see those as: plPgsql (for Oracle people) plPerl plPHP What databases support perl or php stored procs/functions? Or python for that matter? None on the server side (except PostgreSQL) which makes the argument all that more powerful :) Sincerely, Joshua D. Drake -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL begin:vcard fn:Joshua Drake n:Drake;Joshua org:Command Prompt, Inc. adr:;;PO Box 215 ;Cascade Locks;OR;97014;US email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0334 x-mozilla-html:FALSE url:http://www.commandprompt.com version:2.1 end:vcard ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] [HACKERS] plPHP in core?
On Sun, Apr 03, 2005 at 08:41:15PM -0700, Joshua D. Drake wrote: Jim C. Nasby wrote: On Sat, Apr 02, 2005 at 07:29:02AM -0800, Joshua D. Drake wrote: This argument doesn't hold too much weight. Namely because there are only 3-5 really popular languages out there. They are marketing languages. The are languages you include because your database doesn't sound complete with out them. Regardless if you can download them separately. People are lazy. They don't want to download them separately. I see those as: plPgsql (for Oracle people) plPerl plPHP What databases support perl or php stored procs/functions? Or python for that matter? None on the server side (except PostgreSQL) which makes the argument all that more powerful :) So what you're saying is that no database sounds complete because no database includes PHP as a procedural language. Sorry, but I don't buy it. From a database comparison/marketing standpoint, the only languages that matter are C/C++, plpgsql and pljava, because these are the only languages that other databases support. Honestly, I think if we're going to spend time worrying about languages as features then we should be doing more to advertise the fact that perl/PHP/python/ruby/etc programmers can program in the database in their native language. This is something that makes PostgreSQL unique and should provide additional incentive for people to use PostgreSQL. I don't think it matters much at all if those 'bonus languages' are included in core or not, at least not to end-users. -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] [HACKERS] plPHP in core?
Jim C. Nasby [EMAIL PROTECTED] writes: On Sun, Apr 03, 2005 at 08:41:15PM -0700, Joshua D. Drake wrote: What databases support perl or php stored procs/functions? Or python for that matter? None on the server side (except PostgreSQL) which makes the argument all that more powerful :) Actually Oracle supports at least Perl and Java in addition to C for server side code. And of course once you have C it's a SMOP to have PHP, Python, Ruby or whatever so I wouldn't be surprised to find packages for any of those out there. Honestly, I think if we're going to spend time worrying about languages as features then we should be doing more to advertise the fact that perl/PHP/python/ruby/etc programmers can program in the database in their native language. This is something that makes PostgreSQL unique and should provide additional incentive for people to use PostgreSQL. I don't think it matters much at all if those 'bonus languages' are included in core or not, at least not to end-users. FWIW I agree. The extensibility of Postgres is its strong point. That you can program the server easily and conveniently in your favourite language without going through extra layers of abstraction or complicated build environments is the biggest component of that. -- greg ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] [HACKERS] plPHP in core?
In the past couple of years a lot of stuff has been removed from the core - even the ODBC driver (which is ways more important than, let's say, PL/PHP) has been removed from the core - so why should a new PL be integrated now if considerably more important components will remain external? Best regards, Hans Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: I'm not convinced that PLs are more tied to the core than say OpenFTS, and if we can't maintain that kind of thing externally, then this whole extension thing sounds like a failure to me. It's *possible* to do it. Whether it's a net savings of effort is questionable. For instance, I've had to hack plperl and plpgsql over the past couple days to support OUT parameters, and the only reason I didn't have to hack the other two standard PLs is that they are a few features shy of a load already. I'm pretty sure pl/r and pl/java will need changes to support this feature too. If they were in core CVS then I'd consider it part of my responsibility to fix 'em ... but they aren't, so it isn't my problem, so it falls on Joe and Thomas to get up to speed on what I've been doing and do likewise. Is that really a win? The point here is really that we keep finding reasons to, if not flat-out change the interface to PLs, at least expand their responsibilities. Not to push it too hard, but we still have only one PL with a validator procedure, which IIRC was your own addition to that API. How come they don't all have validators? regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Cybertec Geschwinde u Schoenig Schoengrabern 134, A-2020 Hollabrunn, Austria Tel: +43/664/393 39 74 www.cybertec.at, www.postgresql.at ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] [HACKERS] plPHP in core?
pl-j ( the other java procedural language ) is definately interested in being in core. Dave Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: On Fri, 1 Apr 2005, Joshua D. Drake wrote: Are we interested in having plPHP in core? Is there a reason why it can no longer operate as a standalone language out of pgfoundry, like pl/java and pl/perl? PLs are sufficiently tightly tied to the core that it's probably easier to maintain them as part of our core CVS than otherwise. (Ask Joe Conway about PL/R. Thomas Hallgren is probably not that happy about maintaining pl/java out of core, either. And pl/perl *is* in core.) I'm thinking that a pl/PHP is much more interesting for the long term than, say, pl/tcl (mind you, I am a Tcl partisan from way back, but I see that many people are not so enlightened). Barring any licensing problems I think this is something to pursue. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] [HACKERS] plPHP in core?
Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: Also, since plPerlNG is maintained on PgFoundry, are the changes you are making to core getting migrated back to the main project itself? I don't know, and not being a maintainer of the pgfoundry project, it is *definitely* not my problem. But I cannot believe it's a good idea to have two supposedly authoritative CVS repositories for the same code... Core is the authoritative repo for plPerl. pgFoundry is our RD... our Linux 2.1 versus 2.2. Sincerely, Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL begin:vcard fn:Joshua Drake n:Drake;Joshua org:Command Prompt, Inc. adr:;;PO Box 215 ;Cascade Locks;OR;97014;US email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0334 x-mozilla-html:FALSE url:http://www.commandprompt.com version:2.1 end:vcard ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] [HACKERS] plPHP in core?
Marc G. Fournier wrote: One key point to note here is Joshua already saying they wish, like plPerl, to continue maintaining the core code outside of the core distribution ... the way I read that is they just want to be 'in core' to piggy back on the distribution, not to make development/maintenance any easier ... Well that is not exactly what I meant but I see what you are saying. The reason plPerlNG is maintained outside of core and then resubmitted is that we worked on it longer than feature freeze and we made the features work with 7.4 as well. We have not done any work on it, in about 6 months?... I am thinking. ey are a few features shy of a load already. I'm pretty sure pl/r and pl/java will need changes to support this feature too. If they were in core CVS then I'd consider it part of my responsibility to fix 'em But, why should it be your responsibility to fix 'em? This is a good point and I did submit to Tom that as we were the ones that submitted the new plPerl that we would have been happy to do that work. We just didn't know the work was being done. Is it really a win that the only person 'up to speed' that can fix them is you? Seems a load that will grow heavier as more PLs (if more PLs) come online ... This argument doesn't hold too much weight. Namely because there are only 3-5 really popular languages out there. They are marketing languages. The are languages you include because your database doesn't sound complete with out them. Regardless if you can download them separately. People are lazy. They don't want to download them separately. I see those as: plPgsql (for Oracle people) plPerl plPHP plJava plPython is cool and all (I love Python) but feature wise it is quite a bit behind the others and unless someone picks up active development it probably should be removed. FYI: Resources permitting we are looking at plPython If plJava can be integrated in a way that will allow it to be installed easily with the standard mechanism of ./configure --with-pljava then I believe it should be there as well. Also, since plPerlNG is maintained on PgFoundry, are the changes you are making to core getting migrated back to the main project itself? I have not see a patch yet. Sincerely, Joshua D. Drake Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL begin:vcard fn:Joshua Drake n:Drake;Joshua org:Command Prompt, Inc. adr:;;PO Box 215 ;Cascade Locks;OR;97014;US email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0334 x-mozilla-html:FALSE url:http://www.commandprompt.com version:2.1 end:vcard ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] [HACKERS] plPHP in core?
Hans-Jürgen Schönig wrote: In the past couple of years a lot of stuff has been removed from the core - even the ODBC driver (which is ways more important than, let's say, PL/PHP) has been removed from the core - so why should a new PL be integrated now if considerably more important components will remain external? ODBC is a client side driver. It is not a server side driver. It does not require PostgreSQL to be installed. plPHP, plPerl, etc... all require PostgreSQL, they are a part of PostgreSQL whether in core or not. Sincerely, Joshua D. Drake Best regards, Hans Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: I'm not convinced that PLs are more tied to the core than say OpenFTS, and if we can't maintain that kind of thing externally, then this whole extension thing sounds like a failure to me. It's *possible* to do it. Whether it's a net savings of effort is questionable. For instance, I've had to hack plperl and plpgsql over the past couple days to support OUT parameters, and the only reason I didn't have to hack the other two standard PLs is that they are a few features shy of a load already. I'm pretty sure pl/r and pl/java will need changes to support this feature too. If they were in core CVS then I'd consider it part of my responsibility to fix 'em ... but they aren't, so it isn't my problem, so it falls on Joe and Thomas to get up to speed on what I've been doing and do likewise. Is that really a win? The point here is really that we keep finding reasons to, if not flat-out change the interface to PLs, at least expand their responsibilities. Not to push it too hard, but we still have only one PL with a validator procedure, which IIRC was your own addition to that API. How come they don't all have validators? regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL begin:vcard fn:Joshua Drake n:Drake;Joshua org:Command Prompt, Inc. adr:;;PO Box 215 ;Cascade Locks;OR;97014;US email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0334 x-mozilla-html:FALSE url:http://www.commandprompt.com version:2.1 end:vcard ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] [HACKERS] plPHP in core?
Dave Cramer wrote: pl-j ( the other java procedural language ) is definately interested in being in core. Is it actively developed? Not being rude... I just haven't heard much (almost nothing) about it. Sincerely, Joshua D. Drake Dave Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: On Fri, 1 Apr 2005, Joshua D. Drake wrote: Are we interested in having plPHP in core? Is there a reason why it can no longer operate as a standalone language out of pgfoundry, like pl/java and pl/perl? PLs are sufficiently tightly tied to the core that it's probably easier to maintain them as part of our core CVS than otherwise. (Ask Joe Conway about PL/R. Thomas Hallgren is probably not that happy about maintaining pl/java out of core, either. And pl/perl *is* in core.) I'm thinking that a pl/PHP is much more interesting for the long term than, say, pl/tcl (mind you, I am a Tcl partisan from way back, but I see that many people are not so enlightened). Barring any licensing problems I think this is something to pursue. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL begin:vcard fn:Joshua Drake n:Drake;Joshua org:Command Prompt, Inc. adr:;;PO Box 215 ;Cascade Locks;OR;97014;US email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0334 x-mozilla-html:FALSE url:http://www.commandprompt.com version:2.1 end:vcard ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] [HACKERS] plPHP in core?
Very actively, http://plj.codehaus.org Dave Joshua D. Drake wrote: Dave Cramer wrote: pl-j ( the other java procedural language ) is definately interested in being in core. Is it actively developed? Not being rude... I just haven't heard much (almost nothing) about it. Sincerely, Joshua D. Drake Dave Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: On Fri, 1 Apr 2005, Joshua D. Drake wrote: Are we interested in having plPHP in core? Is there a reason why it can no longer operate as a standalone language out of pgfoundry, like pl/java and pl/perl? PLs are sufficiently tightly tied to the core that it's probably easier to maintain them as part of our core CVS than otherwise. (Ask Joe Conway about PL/R. Thomas Hallgren is probably not that happy about maintaining pl/java out of core, either. And pl/perl *is* in core.) I'm thinking that a pl/PHP is much more interesting for the long term than, say, pl/tcl (mind you, I am a Tcl partisan from way back, but I see that many people are not so enlightened). Barring any licensing problems I think this is something to pursue. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] [HACKERS] plPHP in core?
On Sat, 2 Apr 2005, Joshua D. Drake wrote: This argument doesn't hold too much weight. Namely because there are only 3-5 really popular languages out there. They are marketing languages. The are languages you include because your database doesn't sound complete with out them. Regardless if you can download them separately. People are lazy. They don't want to download them separately. Actually, as I've stated many times before, and why I continue to argue against the mega distribution, I *know* that ppl using the *BSDs download them indivdually, as that is how our ports are built: drwxr-xr-x 2 root wheel 512 Feb 4 04:59 p5-postgresql-plperl drwxr-xr-x 2 root wheel 512 Feb 4 04:59 postgresql-plpython drwxr-xr-x 3 root wheel 512 Jan 31 04:59 postgresql-plruby drwxr-xr-x 2 root wheel 512 Feb 4 04:59 postgresql-pltcl Unless postgresql isn't already installed ... In fact, a total break down right now o four ports looks like: drwxr-xr-x 2 root wheel 512 Feb 4 04:59 p5-postgresql-plperl drwxr-xr-x 2 root wheel 512 Feb 4 04:59 postgresql-contrib drwxr-xr-x 3 root wheel 512 Jan 24 04:59 postgresql-devel drwxr-xr-x 2 root wheel 512 Jan 31 04:59 postgresql-docs drwxr-xr-x 3 root wheel 512 Feb 11 04:59 postgresql-jdbc drwxr-xr-x 3 root wheel 512 Jan 31 04:59 postgresql-libpq++ drwxr-xr-x 3 root wheel 512 Jan 31 04:59 postgresql-libpqxx drwxr-xr-x 2 root wheel 512 Dec 6 04:59 postgresql-odbc drwxr-xr-x 2 root wheel 512 Feb 4 04:59 postgresql-plpython drwxr-xr-x 3 root wheel 512 Jan 31 04:59 postgresql-plruby drwxr-xr-x 2 root wheel 512 Feb 4 04:59 postgresql-pltcl drwxr-xr-x 3 root wheel 512 Dec 14 05:01 postgresql-relay drwxr-xr-x 3 root wheel 512 Feb 20 04:59 postgresql-tcltk drwxr-xr-x 2 root wheel 512 Feb 20 04:59 postgresql73-client drwxr-xr-x 3 root wheel 1024 Mar 19 04:59 postgresql73-server drwxr-xr-x 2 root wheel 512 Feb 20 04:59 postgresql74-client drwxr-xr-x 3 root wheel 1024 Mar 19 04:59 postgresql74-server drwxr-xr-x 2 root wheel 512 Feb 20 04:59 postgresql80-client drwxr-xr-x 3 root wheel 1024 Mar 19 04:59 postgresql80-server drwxr-xr-x 2 root wheel 512 Oct 24 04:59 postgresql_autodoc Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] [HACKERS] plPHP in core?
Marc G. Fournier [EMAIL PROTECTED] writes: On Fri, 1 Apr 2005, Joshua D. Drake wrote: Are we interested in having plPHP in core? Is there a reason why it can no longer operate as a standalone language out of pgfoundry, like pl/java and pl/perl? PLs are sufficiently tightly tied to the core that it's probably easier to maintain them as part of our core CVS than otherwise. (Ask Joe Conway about PL/R. Thomas Hallgren is probably not that happy about maintaining pl/java out of core, either. And pl/perl *is* in core.) I'm thinking that a pl/PHP is much more interesting for the long term than, say, pl/tcl (mind you, I am a Tcl partisan from way back, but I see that many people are not so enlightened). Barring any licensing problems I think this is something to pursue. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] [HACKERS] plPHP in core?
I'm thinking that a pl/PHP is much more interesting for the long term than, say, pl/tcl (mind you, I am a Tcl partisan from way back, but I see that many people are not so enlightened). Barring any licensing problems I think this is something to pursue. Per the license issue it is licensed under the PHP and PostgreSQL licenses. Sincerely, Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC Postgresql support, programming shared hosting and dedicated hosting. +1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com PostgreSQL Replicator -- production quality replication for PostgreSQL begin:vcard fn:Joshua Drake n:Drake;Joshua org:Command Prompt, Inc. adr:;;PO Box 215 ;Cascade Locks;OR;97014;US email;internet:[EMAIL PROTECTED] title:Consultant tel;work:503-667-4564 tel;fax:503-210-0334 x-mozilla-html:FALSE url:http://www.commandprompt.com version:2.1 end:vcard ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] [HACKERS] plPHP in core?
Tom Lane wrote: PLs are sufficiently tightly tied to the core that it's probably easier to maintain them as part of our core CVS than otherwise. (Ask Joe Conway about PL/R. As a matter of fact, let's ask him. Thomas Hallgren is probably not that happy about maintaining pl/java out of core, either. And let's ask him, too. I'm not convinced that PLs are more tied to the core than say OpenFTS, and if we can't maintain that kind of thing externally, then this whole extension thing sounds like a failure to me. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] [HACKERS] plPHP in core?
Peter Eisentraut [EMAIL PROTECTED] writes: I'm not convinced that PLs are more tied to the core than say OpenFTS, and if we can't maintain that kind of thing externally, then this whole extension thing sounds like a failure to me. It's *possible* to do it. Whether it's a net savings of effort is questionable. For instance, I've had to hack plperl and plpgsql over the past couple days to support OUT parameters, and the only reason I didn't have to hack the other two standard PLs is that they are a few features shy of a load already. I'm pretty sure pl/r and pl/java will need changes to support this feature too. If they were in core CVS then I'd consider it part of my responsibility to fix 'em ... but they aren't, so it isn't my problem, so it falls on Joe and Thomas to get up to speed on what I've been doing and do likewise. Is that really a win? The point here is really that we keep finding reasons to, if not flat-out change the interface to PLs, at least expand their responsibilities. Not to push it too hard, but we still have only one PL with a validator procedure, which IIRC was your own addition to that API. How come they don't all have validators? regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] [HACKERS] plPHP in core?
On Sat, 2 Apr 2005, Peter Eisentraut wrote: I'm not convinced that PLs are more tied to the core than say OpenFTS, and if we can't maintain that kind of thing externally, then this whole extension thing sounds like a failure to me. As many times as Peter and I butt heads, on this I have to agree ... we're an extensible database that requires the extensions to be in core is effectively what is being said, which kinda defeats the 'extensible' nature ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] [HACKERS] plPHP in core?
One key point to note here is Joshua already saying they wish, like plPerl, to continue maintaining the core code outside of the core distribution ... the way I read that is they just want to be 'in core' to piggy back on the distribution, not to make development/maintenance any easier ... It's *possible* to do it. Whether it's a net savings of effort is questionable. For instance, I've had to hack plperl and plpgsql over the past couple days to support OUT parameters, and the only reason I didn't have to hack the other two standard PLs is that they are a few features shy of a load already. I'm pretty sure pl/r and pl/java will need changes to support this feature too. If they were in core CVS then I'd consider it part of my responsibility to fix 'em But, why should it be your responsibility to fix 'em? ... but they aren't, so it isn't my problem, so it falls on Joe and Thomas to get up to speed on what I've been doing and do likewise. Is that really a win? Is it really a win that the only person 'up to speed' that can fix them is you? Seems a load that will grow heavier as more PLs (if more PLs) come online ... Also, since plPerlNG is maintained on PgFoundry, are the changes you are making to core getting migrated back to the main project itself? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] [HACKERS] plPHP in core?
Marc G. Fournier [EMAIL PROTECTED] writes: Also, since plPerlNG is maintained on PgFoundry, are the changes you are making to core getting migrated back to the main project itself? I don't know, and not being a maintainer of the pgfoundry project, it is *definitely* not my problem. But I cannot believe it's a good idea to have two supposedly authoritative CVS repositories for the same code... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] [HACKERS] plPHP in core?
Tom Lane wrote: The point here is really that we keep finding reasons to, if not flat-out change the interface to PLs, at least expand their responsibilities. Not to push it too hard, but we still have only one PL with a validator procedure, which IIRC was your own addition to that API. How come they don't all have validators? Point taken. The reason was, as explained the other day, that before the arrival of the trigger pseudotype it was not really possible to implement that in some cases. But I plan to follow up on that now. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
