plPHP in core?

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 having plPHP in core?

Yes, I think so.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Fri, Apr 01, 2005 at 07:11:14PM -0800, Joshua D. Drake wrote:

Hi Joshua,

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 having plPHP in core?

Is the license compatible?

--
Alvaro Herrera (<alvherre[@]dcc.uchile.cl>)
"Now I have my system running, not a byte was off the shelf;
It rarely breaks and when it does I fix the code myself.
It's stable, clean and elegant, and lightning fast as well,
And it doesn't cost a nickel, so Bill Gates can go to hell."

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

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

"Marc G. Fournier" <scrappy@postgresql.org> 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

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 functions support.
With full support pl/PHP must come into core.
Yes licence issues are left to licence experts.

--
With Best Regards,
Vishal Kashyap.
Lead Software Developer,
http://saihertz.com,
http://vishalkashyap.tk

Alvaro Herrera wrote:

On Fri, Apr 01, 2005 at 07:11:14PM -0800, Joshua D. Drake wrote:

Hi Joshua,

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 having plPHP in core?

Is the license compatible?

Yes we have licensed it under the PostgreSQL & PHP license.

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 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL

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

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?

Well plPerl is in core and also on pgFoundry as we continue to develop both.
We would like to do the same for plPHP.

Sincerely,

Joshua D. Drake

----
Marc G. Fournier Hub.Org Networking Services
(http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ:
7615664

-- 
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL

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 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL

Joshua D. Drake wrote:

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.

How can that be?

Are we interested in having plPHP in core?

Personally, I'm not too excited about it.

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

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/

Peter Eisentraut <peter_e@gmx.net> 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

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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

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: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

"Marc G. Fournier" <scrappy@postgresql.org> 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

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/

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> 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?

So far we've been able to keep up with PostgreSQL changes because a) the
interfaces are after all pretty well defined, and b) there is always a
long enough delay between changes of the interfaces and their official
release to make it possible for us to catch up. Cumbersome sure, but
still not my primary concern. There's a couple of other reasons why it's
bad to be an "outsider".

a) If skilled core developers from time to time stumbled on compilation
errors in PL/Java due to changes made in the backend, then I believe
that this would result in some level of code review and perhaps lots of
good criticism and ideas of improvement.

b) I've been forced to do pull some tricks in PL/Java to work around
things that I consider lacking in the interfaces. Having PL/Java in core
would make it possible to work together more tightly in order to find
good solutions/API's that can benefit all PL's.

c) PL/Java would become (optional?) part of the build and the regression
tests. It would be great to get early warnings when things change that
break PL/Java.

d) Bringing PL/Java into core will force a consistent documentation and,
I imagine, a chapter of it's own in the main docs. I'm happy to write
most of it but English is not my native language. Whatever I put into
print will always benefit from a review.

e) The article http://www.powerpostgresql.com/5_types describes another
serious issue pretty well. While it's easy for an organization to become
dependent on the "Community" based PostgreSQL, it's much more difficult
to make such a decision with the "Solo" based PL/Java.

In essence, I'm all for bringing PL/Java into core. While doing so I
think it's imperative to maintain good API's between modules and
backend. Bringing the PL's into core must be done while retaining good
separation of concern. The extension mechanism is a good thing. It
should be improved regardless where PL's end up.

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?

For PL/Java, the answer is that we just haven't had the time to
implement it. It should be done of course.

Regards,
Thomas Hallgren

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> 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?

So far we've been able to keep up with PostgreSQL changes because a) the
interfaces are after all pretty well defined, and b) there is always a
long enough delay between changes of the interfaces and their official
release to make it possible for us to catch up. Cumbersome sure, but
still not my primary concern. There's a couple of other reasons why it's
bad to be an "outsider".

a) If skilled core developers from time to time stumbled on compilation
errors in PL/Java due to changes made in the backend, then I believe
that this would result in some level of code review and perhaps lots of
good criticism and ideas of improvement.

b) I've been forced to do pull some tricks in PL/Java to work around
things that I consider lacking in the interfaces. Having PL/Java in core
would make it possible to work together more tightly in order to find
good solutions/API's that can benefit all PL's.

c) PL/Java would become (optional?) part of the build and the regression
tests. It would be great to get early warnings when things change that
break PL/Java.

d) Bringing PL/Java into core will force a consistent documentation and,
I imagine, a chapter of it's own in the main docs. I'm happy to write
most of it but English is not my native language. Whatever I put into
print will always benefit from a review.

e) The article http://www.powerpostgresql.com/5_types describes another
serious issue pretty well. While it's easy for an organization to become
dependent on the "Community" based PostgreSQL, it's much more difficult
to make such a decision with the "Solo" based PL/Java.

In essence, I'm all for bringing PL/Java into core. While doing so I
think it's imperative to maintain good API's between modules and
backend. Bringing the PL's into core must be done while retaining good
separation of concern. The extension mechanism is a good thing. It
should be improved regardless where PL's end up.

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?

For PL/Java, the answer is that we just haven't had the time to
implement it. It should be done of course.

Regards,
Thomas Hallgren

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 <peter_e@gmx.net> 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

Peter Eisentraut wrote:

Joshua D. Drake wrote:

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.

How can that be?

I am not sure I understand the question but we are
linking against the .so now. So as long as PHP
is and PostgreSQL ./configure knows where to look
we should be good.

Sincerely,

Joshua D. Drake

Are we interested in having plPHP in core?

Personally, I'm not too excited about it.

-- 
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL