Joshua D. Drake wrote:
Or were you trying to say let's ship it, and I don't care if major
Linux distributors refuse to include it in their packaging because it's
too hard to build that way?
Close but not quite :). I was saying that Linux distributors are
going to do what their users
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
Martijn van Oosterhout wrote:
I suppose the choice comes down to either PHP splitting the DB access
(like other languages) or PostgreSQL splitting out pl/PHP.
Most major distributions (Fedora Core, Debian, Redhat) splits core php
and database-access in different packages. Might be that sqlite is
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,
On Tue, Apr 05, 2005 at 11:17:48AM +0200, Robin Ericsson wrote:
Martijn van Oosterhout wrote:
I suppose the choice comes down to either PHP splitting the DB access
(like other languages) or PostgreSQL splitting out pl/PHP.
Most major distributions (Fedora Core, Debian, Redhat) splits core
Martijn van Oosterhout wrote:
On Tue, Apr 05, 2005 at 11:17:48AM +0200, Robin Ericsson wrote:
Martijn van Oosterhout wrote:
I suppose the choice comes down to either PHP splitting the DB access
(like other languages) or PostgreSQL splitting out pl/PHP.
Most major distributions (Fedora 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.
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
On Mon, 2005-04-04 at 19:52, Paul Tillotson wrote:
Joshua D. Drake wrote:
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
Robin Ericsson [EMAIL PROTECTED] writes:
Martijn van Oosterhout wrote:
I suppose the choice comes down to either PHP splitting the DB access
(like other languages) or PostgreSQL splitting out pl/PHP.
Most major distributions (Fedora Core, Debian, Redhat) splits core php
and database-access
=?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
The proposal on the table is to bundle plPHP into the Postgres source
package, and the problem is that that introduces a circular dependency
at build time because PHP already made a similar bundling. That was a
bad move on their part and we shouldn't compound the problem by making
a similar
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
Le mardi 05 avril 2005 à 08:26 -0700, Joshua D. Drake a écrit :
Frankly I don't think we should care if PHP is borked on
their API or build process. We should care if plPHP is:
A. Quality enough software (and yes it needs some work) to
go into core.
B. Appropriate for the PostgreSQL user
Joshua D. Drake [EMAIL PROTECTED] writes:
I understand your point Tom. However as I said in a earlier
post, just because it is in core doesn't mean they have to
package it.
If it were in our CVS, but still shipped as an separate, independently-built
source package, then my objection would not
tony [EMAIL PROTECTED] writes:
I just caught on to this thread. For those of us who don't want PHP
withing shouting distance of our PostgreSQL server what does this mean?
Nothing. You'll always have the option to not build plPHP and/or not
install it, no matter what we do or don't do with the
Scott Marlowe wrote:
What I would much prefer is a matrix that shows all the features a PL
should / could have, and which PLs have those features, which features
are currently being implemented, who maintains them if they are
maintained, if they aren't maintained, etc.. So that when it comes time
Obviously my opinion is that B is met and A is being worked
on.
I just caught on to this thread. For those of us who don't want PHP
withing shouting distance of our PostgreSQL server what does this mean?
It means nothing. If you don't want to use plPHP don't :)
I don't trust PHP or its
Or were you trying to say let's ship it, and I don't care if major
Linux distributors refuse to include it in their packaging because it's
too hard to build that way?
Close but not quite :). I was saying that Linux distributors are
going to do what their users want. Otherwise the distribution
[Cc: list purged a bit]
On Sun, 3 Apr 2005, Jim C. Nasby wrote:
On Sun, Apr 03, 2005 at 08:41:15PM -0700, Joshua D. Drake wrote:
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
Sorry, but I don't buy it.
I do. Actually I think no database is complete because no one includes
LISP as a procedural language (pun on procedural intented).
(BTW, I have no idea if a pl/LISP module ever existed.)
O.k. this is just a little sick ;0... Module-2 here I come.
Sincerely,
Joshua D.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Joshua D. Drake wrote:
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.
Although
Paul Tillotson [EMAIL PROTECTED] writes:
Thus, even though I know very little about Ruby or TCL, I would gladly
learn one of those if I knew that plruby or pltcl did all the stuff that
a pl should (wasn't missing functionality such as writing triggers,
set-returning functions), was
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
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
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
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?
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
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
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
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:
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
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.
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
On Sat, 2 Apr 2005, Dave Cramer wrote:
pl-j ( the other java procedural language ) is definately interested in
being in core.
Yet anothre good reason *not* to be including PLs ... similar to why we
moved libpq++ out of core ... I may be wrong, but I doubt that pl-j has
the same feature set as
Joshua D. Drake wrote:
Hello,
We at Command Prompt are in the process of completing
a new rev of plPHP. The new rev will not require the
PHP source. It will only require that PHP is installed.
In other words it can be installed just like any other pl
language.
Are we interested in
On Fri, 1 Apr 2005, Joshua D. Drake wrote:
Hello,
We at Command Prompt are in the process of completing
a new rev of plPHP. The new rev will not require the
PHP source. It will only require that PHP is installed.
In other words it can be installed just like any other pl
language.
Are we interested
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
In other words it can be installed just like any other pl
language.
Are we interested in having plPHP in core?
Yes , it must come into the core as PHP developers would now get
tempted to write functions inside database this would cut out
adoption of Databases which do not have PHP type
Marc G. Fournier wrote:
On Fri, 1 Apr 2005, Joshua D. Drake wrote:
Hello,
We at Command Prompt are in the process of completing
a new rev of plPHP. The new rev will not require the
PHP source. It will only require that PHP is installed.
In other words it can be installed just like any other pl
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
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,
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
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
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 ...
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
62 matches
Mail list logo
