Thread: plPHP in core?

plPHP in core?

From
"Joshua D. Drake"
Date:
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?

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


Attachment

Re: [HACKERS] plPHP in core?

From
Bruce Momjian
Date:
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

Re: plPHP in core?

From
Alvaro Herrera
Date:
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."

Re: [HACKERS] plPHP in core?

From
"Marc G. Fournier"
Date:
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

Re: [HACKERS] plPHP in core?

From
Tom Lane
Date:
"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

Re: [HACKERS] plPHP in core?

From
"Vishal Kashyap @ [SaiHertz]"
Date:
> 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

Re: plPHP in core?

From
"Joshua D. Drake"
Date:
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


Attachment

Re: [HACKERS] plPHP in core?

From
"Joshua D. Drake"
Date:
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


Attachment

Re: [HACKERS] plPHP in core?

From
"Joshua D. Drake"
Date:
>
>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


Attachment

Re: [HACKERS] plPHP in core?

From
Peter Eisentraut
Date:
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/

Re: [HACKERS] plPHP in core?

From
Tom Lane
Date:
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

Re: [HACKERS] plPHP in core?

From
"Marc G. Fournier"
Date:
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

Re: [HACKERS] plPHP in core?

From
"Marc G. Fournier"
Date:
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

Re: [HACKERS] plPHP in core?

From
Tom Lane
Date:
"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

Re: plPHP in core?

From
Thomas Hallgren
Date:
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


Re: [HACKERS] plPHP in core?

From
Hans-Jürgen Schönig
Date:
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


Re: [HACKERS] plPHP in core?

From
Dave Cramer
Date:
pl-j ( the other java procedural language ) is definately interested in
being in core.

Dave

Tom Lane wrote:

>"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
>
>---------------------------(end of broadcast)---------------------------
>TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>
>
>
>


Re: [HACKERS] plPHP in core?

From
"Joshua D. Drake"
Date:
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: scrappy@hub.org           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 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL


Attachment

Re: [HACKERS] plPHP in core?

From
"Joshua D. Drake"
Date:
Tom Lane wrote:

>"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...
>
>
Core is the authoritative repo for plPerl. pgFoundry
is our R&D... 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 majordomo@postgresql.org
>
>


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


Attachment

Re: [HACKERS] plPHP in core?

From
"Joshua D. Drake"
Date:
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 <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
>
>
>


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


Attachment

Re: [HACKERS] plPHP in core?

From
"Joshua D. Drake"
Date:
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" <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
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>>
>>
>>
>>


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


Attachment

Re: [HACKERS] plPHP in core?

From
Dave Cramer
Date:
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" <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
>>>
>>> ---------------------------(end of
>>> broadcast)---------------------------
>>> TIP 1: subscribe and unsubscribe commands go to
>>> majordomo@postgresql.org
>>>
>>>
>>>
>>>
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 7: don't forget to increase your free space map settings
>
>


Re: [HACKERS] plPHP in core?

From
"Marc G. Fournier"
Date:
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: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Re: plPHP in core?

From
Joe Conway
Date:
Thomas Hallgren wrote:
> Tom Lane wrote:

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

This has also been my experience. Every Postgres development cycle has
seen a half dozen or so backend changes that break PL/R. It usually
doesn't take too long to respond to the changes though.

> a) If skilled core developers from time to time stumbled on compilation
> b) I've been forced to do pull some tricks in PL/Java to work around
> c) PL/Java would become (optional?) part of the build and the regression
> d) Bringing PL/Java into core will force a consistent documentation and,

Agreed.

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

This one is particularly important. I'm currently responsible for a
commercial project at work that sits on the shoulders of a good deal of
open source software. We've specifically needed to either avoid
components with single or a small number of maintainers, or make a
conscious decision to accept permanent responsibility to maintain the
code should the "Solo" disappear (and dedicate enough resource to become
comfortable with that code). Like it or not, I think everything
relegated to pgfoundry suffers from this to some degree. There is no
doubt in my mind that both PL/R and PL/Java would get much wider use
(and therefore wider testing and code review) if they were packaged with
the core Postgres distribution.

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

Agreed. Time has been hard for me to come by lately :(

Joe

Re: plPHP in core?

From
"Marc G. Fournier"
Date:
On Sat, 2 Apr 2005, Thomas Hallgren wrote:

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

Submitting bug reports, or asking on -hackers, would have the same effect
...

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

There is nothing stop'ng a chapter being added now, and a pointer to where
to download it could be easily added as part of it ..

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

Re: [HACKERS] plPHP in core?

From
"Marc G. Fournier"
Date:
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 pl-java, or vs versa ... so, what do we do?
each time someone argues for a better widget, we swap out the old and
include the new?  there is no guarantee that plPHP will be the only PHP
based PL out there, any more then the other PLs, or language libraries ...

*If* something *requires* the physical postgresql source code to be
available (not just the isntalled headers/libraries), like libpq does,
then it makes sense to be part of the core distribution ... but, IMHO, the
core distribution shouldn't be 'the means to validation' of an interface,
since it unfairly negates work that someone else might be working on (ie.
in this case, Dave's pl-j alternative to pl-java) ...

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

Re: [HACKERS] plPHP in core?

From
Peter Eisentraut
Date:
Marc G. Fournier wrote:
> > 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.
>
> There is nothing stop'ng a chapter being added now,

Actually there is: We don't ship documentation for software that we
don't ship.

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

Re: [HACKERS] plPHP in core?

From
Rod Taylor
Date:
On Sat, 2005-04-02 at 21:48 +0200, Peter Eisentraut wrote:
> Marc G. Fournier wrote:
> > > 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.
> >
> > There is nothing stop'ng a chapter being added now,
>
> Actually there is: We don't ship documentation for software that we
> don't ship.

Very well, rephrase that a little.

There is nothing stopping additional links to documentation from being
added to the PostgreSQL website in the documentation section.
--


test

From
"YL"
Date:
please ignore


--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.9.1 - Release Date: 4/1/2005


Re: [HACKERS] plPHP in core?

From
Peter Eisentraut
Date:
Rod Taylor wrote:
> There is nothing stopping additional links to documentation from
> being added to the PostgreSQL website in the documentation section.

That is true, but that does not foster consistent documentation, which
is what Thomas Hallgren wanted.

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

psql and mysql

From
"YL"
Date:
Dear List,
I'm new to Psql and very eager to learn the differences between these two
RDBMS.
Any help is greatly appreciated.
Thanks



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.9.1 - Release Date: 4/1/2005


Re: psql and mysql

From
Christopher Browne
Date:
Martha Stewart called it a Good Thing when elim@pdtnetworks.net ("YL") wrote:
> Dear List,
> I'm new to Psql and very eager to learn the differences between these two
> RDBMS.

Well, you can find the documentation for PostgreSQL at
<http://www.postgresql.org/>, and you can find the documentation for
MySQL(tm) at <http://www.mysql.com/>.

They are quite different systems; to get any sort of comprehensive
view, you will need to comprehensively read both sets of
documentation.
--
select 'cbbrowne' || '@' || 'gmail.com';
http://linuxfinances.info/info/x.html
Wiener's Law of Libraries:
        There are no answers, only cross references.

Re: psql and mysql

From
jcradock@me3.com
Date:
A significant difference, and something that might be frustrating, is
listing databases and database objects and describing tables. To list
databases, type

\l

...and hit RETURN. To list tables in the database you've logged in to, type

\dt

If you've got some familiarity with MySQL then querying database objects
should be easy in PostgreSQL, altough PostgreSQL does obviously support
some features and thus some commands not available in MySQL. There will be
some learning there, possibly, but I think you'll find it easy. Type

\?

...and press RETURN to see the full set of options. I definitely recommend
reading the docs:

http://www.postgresql.org/docs/current/static/app-psql.html

Enjoy!

Jim

> Dear List,
> I'm new to Psql and very eager to learn the differences between these two
> RDBMS.
> Any help is greatly appreciated.
> Thanks
>
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.9.1 - Release Date: 4/1/2005
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>



-----
James Cradock, jcradock@me3.com



Re: psql and mysql

From
jcradock@me3.com
Date:
Clients aside, and as Christopher wrote, there are lots of differences
between the two systems. PostgreSQL supports higher-end Enterprise-level
RDBMS features. MySQL tends to be quicker. For example, and as just one
example, PostgreSQL can store and handle GIS data through PostGIS. MySQL's
OGC-compatible OGC support was introduced in the latest production-worthy
release. Both MySQL and PostgreSQL are stable and easy to use and well
supported. If you're trying to learn something, I definitely recommend
reading the documentation. If you have some specific task in mind and
think PostgreSQL might be the better fit, post a question to the list.

Jim

> Dear List,
> I'm new to Psql and very eager to learn the differences between these two
> RDBMS.
> Any help is greatly appreciated.
> Thanks
>
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.9.1 - Release Date: 4/1/2005
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>



-----
James Cradock, jcradock@me3.com



Re: [HACKERS] plPHP in core?

From
Christopher Kings-Lynne
Date:
>>>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.
>>
>>There is nothing stop'ng a chapter being added now,
>
>
> Actually there is: We don't ship documentation for software that we
> don't ship.

How about we start a new standard extensions manual on pgFoundry, and
give the documentors from all the main extension projects commits on it.
  That way it's all in one place :)

Or at least a PL's manual...

Chris

Re: [HACKERS] plPHP in core?

From
"Jim C. Nasby"
Date:
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               decibel@decibel.org
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?"

Re: psql and mysql

From
"Jim C. Nasby"
Date:
On Sat, Apr 02, 2005 at 06:23:56PM -0500, jcradock@me3.com wrote:
> Clients aside, and as Christopher wrote, there are lots of differences
> between the two systems. PostgreSQL supports higher-end Enterprise-level
> RDBMS features. MySQL tends to be quicker. For example, and as just one

MySQL is generally only quicker if you don't care about your data
(MyISAM tables) and if you aren't hitting it with multiple clients.
--
Jim C. Nasby, Database Consultant               decibel@decibel.org
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?"

Re: [HACKERS] plPHP in core?

From
"Joshua D. Drake"
Date:
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 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL


Attachment

Re: [HACKERS] plPHP in core?

From
"Jim C. Nasby"
Date:
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               decibel@decibel.org
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?"

Re: [HACKERS] plPHP in core?

From
Marco Colombo
Date:
[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
> database includes PHP as a procedural language.
>
> 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.)

.TM.
--
       ____/  ____/   /
      /      /       /            Marco Colombo
     ___/  ___  /   /              Technical Manager
    /          /   /             ESI s.r.l.
  _____/ _____/  _/               Colombo@ESI.it

Re: [HACKERS] plPHP in core?

From
"Joshua D. Drake"
Date:
>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 - jd@commandprompt.com - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL


Attachment

Re: [HACKERS] plPHP in core?

From
"Joshua D. Drake"
Date:
>>
>> 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. Drake



>
> .TM.



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


Attachment

Re: [HACKERS] plPHP in core?

From
Andrew Dunstan
Date:

Tom Lane wrote:

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


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

>
>

Re: [HACKERS] plPHP in core?

From
Tom Lane
Date:
Andrew Dunstan <andrew@dunslane.net> 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

Re: [HACKERS] plPHP in core?

From
Andrew Dunstan
Date:

Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.net> 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

Re: [HACKERS] plPHP in core?

From
Robert Treat
Date:
On Monday 04 April 2005 12:01, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> 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

Re: [HACKERS] plPHP in core?

From
"Joshua D. Drake"
Date:
Tom Lane wrote:

>Andrew Dunstan <andrew@dunslane.net> 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
>


Re: [HACKERS] plPHP in core?

From
Tom Lane
Date:
Robert Treat <xzilla@users.sourceforge.net> 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

Re: [HACKERS] plPHP in core?

From
Andrew Dunstan
Date:

Robert Treat wrote:

>On Monday 04 April 2005 12:01, Tom Lane wrote:
>
>
>>Andrew Dunstan <andrew@dunslane.net> 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

Re: [HACKERS] plPHP in core?

From
"Joshua D. Drake"
Date:
> 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



Re: [HACKERS] plPHP in core?

From
Tom Lane
Date:
"Joshua D. Drake" <jd@commandprompt.com> 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

Re: [HACKERS] plPHP in core?

From
Robert Treat
Date:
On Mon, 2005-04-04 at 16:17, Tom Lane wrote:
> Robert Treat <xzilla@users.sourceforge.net> 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


Re: [HACKERS] plPHP in core?

From
"Joshua D. Drake"
Date:
Tom Lane wrote:

>"Joshua D. Drake" <jd@commandprompt.com> 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 majordomo@postgresql.org so that your
>      message can get through to the mailing list cleanly
>
>


Re: [HACKERS] plPHP in core?

From
Doug McNaught
Date:
Robert Treat <xzilla@users.sourceforge.net> 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

Re: [HACKERS] plPHP in core?

From
Alvaro Herrera
Date:
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 (<alvherre[@]dcc.uchile.cl>)
"If it wasn't for my companion, I believe I'd be having
the time of my life"  (John Dunbar)

Re: [HACKERS] plPHP in core?

From
Robert Treat
Date:
On Mon, 2005-04-04 at 17:00, Doug McNaught wrote:
> Robert Treat <xzilla@users.sourceforge.net> 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


Re: [HACKERS] plPHP in core?

From
Robert Treat
Date:
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 (<alvherre[@]dcc.uchile.cl>)
> "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


Re: [HACKERS] plPHP in core?

From
"Joshua D. Drake"
Date:
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.
>
>
>


Re: [HACKERS] plPHP in core?

From
Paul Tillotson
Date:
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 others may like the ability to choose their PL language, I
would like it better if the important developers would pick one (and
only one) high-level scripting language (i.e., one that has built in
hashes, dynamic variable scoping, and the like), and declare it to be
the "sanctioned" language.  (Others could still work on optional
languages as they do now.)

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 efficiently implemented, was well tested,
and was installed by default.

Regards,

Paul Tillotson

Re: [HACKERS] plPHP in core?

From
Tom Lane
Date:
Paul Tillotson <pntil@shentel.net> 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 efficiently implemented, was well tested,
> and was installed by default.

Well, *none* of the PLs except plpgsql are ever going to be built or
installed "by default", because we won't make the default build
configuration depend on packages that are likely not to be present.

            regards, tom lane

Re: [HACKERS] plPHP in core?

From
Russell Smith
Date:
On Tue, 5 Apr 2005 06:01 am, Joshua D. Drake wrote:
> Tom Lane wrote:
>
> >Andrew Dunstan <andrew@dunslane.net> 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

Re: [HACKERS] plPHP in core?

From
Martijn van Oosterhout
Date:
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.

Attachment

Re: [HACKERS] plPHP in core?

From
Robin Ericsson
Date:
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 core,
that newer php that have that change also bundles libsqlite.

php
php-mysql
php-pgsql
...



regards,
    Robin

Re: [HACKERS] plPHP in core?

From
Martijn van Oosterhout
Date:
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 php
> and database-access in different packages. Might be that sqlite is core,
> that newer php that have that change also bundles libsqlite.

Ah yes, I meant to check this but packages.debian.org is down. From my
Sources file, php3-pgsql is generated from the main php3 package. But
php4-pgsql has its own source bundle. Maybe the problem is solved?
--
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.

Attachment

Re: [HACKERS] plPHP in core?

From
Robin Ericsson
Date:
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, Debian, Redhat) splits core php
>>and database-access in different packages. Might be that sqlite is core,
>>that newer php that have that change also bundles libsqlite.
>
>
> Ah yes, I meant to check this but packages.debian.org is down. From my
> Sources file, php3-pgsql is generated from the main php3 package. But
> php4-pgsql has its own source bundle. Maybe the problem is solved?

Ah, you mean it that way. I can't say for debian as the site is still
down :) But atleast Fedore Core uses one main package to generate all
binary packages, so I guess the problem is still there.


regards,
    Robin

Re: [HACKERS] plPHP in core?

From
Martín Marqués
Date:
El Lun 04 Abr 2005 17:36, Tom Lane escribió:
> "Joshua D. Drake" <jd@commandprompt.com> 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
-----------------------------------------------------------------

Re: [HACKERS] plPHP in core?

From
Martín Marqués
Date:
El Lun 04 Abr 2005 18:00, Doug McNaught escribió:
> Robert Treat <xzilla@users.sourceforge.net> 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
-----------------------------------------------------------------

Re: [HACKERS] plPHP in core?

From
Scott Marlowe
Date:
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
> >> their native language.
> >>
> > I agree with you completely.
> >
> Although others may like the ability to choose their PL language, I
> would like it better if the important developers would pick one (and
> only one) high-level scripting language (i.e., one that has built in
> hashes, dynamic variable scoping, and the like), and declare it to be
> the "sanctioned" language.  (Others could still work on optional
> languages as they do now.)
>
> 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 efficiently implemented, was well tested,
> and was installed by default.

There are some points in this idea I like, and some I don't.

I completely understand the point that no one wants to pick a PL, only
to get halfway through learning it when you find out that it doesn't do
one or two things you really want your PL to do, and having to learn
another PL.

However, given the constantly changing landscape of PLs, with things
like the recent issue of Python being safe, then not being safe, then
being safe again, it's hard to say that one particular PL or subset of
PLs is (are) the blessed one(s).

Now, if there were no features that PL/PGSQL left out, then it would be
the one true PL.  But there are a few things it's just not as good at as
tcl or a few other PLs.

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
to choose one, you can make an informed decision ahead of time.

Then, when a PL was deemed to be stable, fully featured, and well
maintained, it could possibly be included in the base distro as a mature
tool.

I don't see a reason to artificially limit the choices to one and only
one language, but do see the reasons to limit it to the mature and fully
implemented ones.

Then again, I'd much rather have them be completely modular so you just
download the pl packages of your choice and install them yourself.

Re: [HACKERS] plPHP in core?

From
Tom Lane
Date:
Robin Ericsson <robin.ericsson@profecta.se> 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 in different packages. Might be that sqlite is core,
> that newer php that have that change also bundles libsqlite.

Look, folks, one more time: this has zero to do with how the installable
packages are divided up.  The problem has to do with how the *source*
packages are divided up, and the rule is you want to build the source
packages in a particular sequence without any circular dependencies.
How many RPMs/DEBs/whatevers come out of a particular source package
really doesn't affect this.

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

            regards, tom lane

Re: [HACKERS] plPHP in core?

From
Tom Lane
Date:
=?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

Re: [HACKERS] plPHP in core?

From
"Joshua D. Drake"
Date:
>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 error.
>
>
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.

The users themselves will either generate the demand for the
package or not, and the packagers can then choose based on
that demand.

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

Obviously my opinion is that B is met and A is being worked
on.

Sincerely,

Joshua D. Drake



>            regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 4: Don't 'kill -9' the postmaster
>
>


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


Attachment

Re: [HACKERS] plPHP in core?

From
"Marc G. Fournier"
Date:
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: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664

Re: [HACKERS] plPHP in core?

From
tony
Date:
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 base.
>
> 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?
I don't trust PHP or its developers anywhere within the distance of a
long pole... (ancient history but once burned always shy)

Tony


Re: [HACKERS] plPHP in core?

From
Tom Lane
Date:
"Joshua D. Drake" <jd@commandprompt.com> 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 apply.  However such a setup
seems to lose a lot of the synergy that is being claimed for having it
in our CVS.  plPHP would then still have its own separate configure and
build process, and it wouldn't get tested "for free" in the same kind of
way that the current core PLs do.

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"?  Somehow that doesn't seem to square with
the goal of making plPHP more available rather than less so.

            regards, tom lane

Re: [HACKERS] plPHP in core?

From
Tom Lane
Date:
tony <tony@tgds.net> 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 source packaging.

            regards, tom lane

Re: [HACKERS] plPHP in core?

From
Russ Brown
Date:
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
> to choose one, you can make an informed decision ahead of time.
>
>

The Matrix idea is a very good one.

I'd also like to see the same for replication solutions too. We all know
that there is no one replication system to suit all situations: such a
matrix would make it much easier to decide which one actually *does*
suit the situation you have in mind.

--

Russ.

Re: [HACKERS] plPHP in core?

From
"Joshua D. Drake"
Date:
>>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 developers anywhere within the distance of a
>long pole... (ancient history but once burned always shy)
>
>Tony
>
>


Re: [HACKERS] plPHP in core?

From
"Joshua D. Drake"
Date:
>
>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
dies.

So just because it is in core doesn't mean they have to package.
Also, alot of people compile from tarball to get an optimized version.
So having plPHP in core would be helpful for them.

>  Somehow that doesn't seem to square with
>the goal of making plPHP more available rather than less so.
>
>
Very true :)

Sincerely,

Joshua D. Drake


>            regards, tom lane
>
>


Re: [HACKERS] plPHP in core?

From
Bruce Momjian
Date:
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 want. Otherwise the distribution
> dies.
>
> So just because it is in core doesn't mean they have to package.
> Also, alot of people compile from tarball to get an optimized version.
> So having plPHP in core would be helpful for them.
>
> >  Somehow that doesn't seem to square with
> >the goal of making plPHP more available rather than less so.
> >
> >
> Very true :)

I read this thread on dependency and plphp.  I think the major issues
are circular dependencies and maintainability.

One of the big reasons for shipping PL languages as part of our
distribution is that they are so closely tied to the backend that it is
hard for them to make versions that work with different releases of the
PostgreSQL internals, so they just ship with a specific version of
PostgreSQL. This is why ecpg is also part of our source tree because it
is tied the grammar.  We _could_ decouple it and the PL languages, but
it is more trouble than it is worth.

I understand what Tom is saying --- that putting pl/php into our tree
adds a cirular dependency that didn't exist before.  Right now it is:

    pg -> php -> pl/php

and with it integrated into our build it is:

    pg (no pl/php)-> php -> pg with pl/php

However, we don't have to compile pl/php by default, and in fact we
don't compile pl/perl by default either.

I think a good solution would be to add pl/php into our tree and print a
message end of the configure run stating that pl/php has to be
compiled/installed manually from the src/pl/php directory after PHP is
installed, of course only if pl/php is enabled as a configure flag.

This gets pl/php into our tree (for easy maintenance), but eliminates
the circular dependency.

(FYI, PL/R isn't distributed with PostgreSQL because of its license.)

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