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
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,
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,
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
=?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
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
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
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
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 [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
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
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
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
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
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
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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
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
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
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
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
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:
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
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
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
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
46 matches
Mail list logo
