Re: plPHP -- sort of an announcement.. but not commercial

Hello,

As a recent flurry of activity has commenced within Command Prompt we
have released
upon this rather unround earth, plPHP. Yes it is trigger safe, yes you
can write UDF's in
PostgreSQL with PHP now.

Find it here:

http://www.commandprompt.com/entry.lxp?lxpe=260

Have a glorius weekend.

Sincerely,

Joshua D. Drake

On Fri, 2003-08-01 at 19:06, Joshua D. Drake wrote:
> Hello,
>
> As a recent flurry of activity has commenced within Command Prompt we
> have released
> upon this rather unround earth, plPHP. Yes it is trigger safe, yes you
> can write UDF's in
> PostgreSQL with PHP now.
>
> Find it here:
>
> http://www.commandprompt.com/entry.lxp?lxpe=260

Is there a possibility of getting this in v7.5?

--
+-----------------------------------------------------------------+
| Ron Johnson, Jr. Home: ron(dot)l(dot)johnson(at)cox(dot)net |
| Jefferson, LA USA |
| |
| "I'm not a vegetarian because I love animals, I'm a vegetarian |
| because I hate vegetables!" |
| unknown |
+-----------------------------------------------------------------+

On Fri, Aug 01, 2003 at 05:06:00PM -0700, Joshua D. Drake wrote:
> Hello,
>
> As a recent flurry of activity has commenced within Command Prompt we
> have released
> upon this rather unround earth, plPHP. Yes it is trigger safe, yes you
> can write UDF's in
> PostgreSQL with PHP now.

Very nice.

Is it in the public domain? I don't see any copyright nor license
mention in the source code...

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"In Europe they call me Niklaus Wirth; in the US they call me Nickel's worth.
That's because in Europe they call me by name, and in the US by value!"

This is very exciting, is this stable, production ready, etc?

Gavin

Alvaro Herrera wrote:

>On Fri, Aug 01, 2003 at 05:06:00PM -0700, Joshua D. Drake wrote:
>
>
>>Hello,
>>
>> As a recent flurry of activity has commenced within Command Prompt we
>>have released
>>upon this rather unround earth, plPHP. Yes it is trigger safe, yes you
>>can write UDF's in
>>PostgreSQL with PHP now.
>>
>>
>
>Very nice.
>
>Is it in the public domain? I don't see any copyright nor license
>mention in the source code...
>
>
>

Hello,

Well PHP is GPL... thus we left it GPL... it belongs to the
community. Enjoy :)

J

Alvaro Herrera wrote:
> On Fri, Aug 01, 2003 at 05:06:00PM -0700, Joshua D. Drake wrote:
>
>>Hello,
>>
>> As a recent flurry of activity has commenced within Command Prompt we
>>have released
>>upon this rather unround earth, plPHP. Yes it is trigger safe, yes you
>>can write UDF's in
>>PostgreSQL with PHP now.
>
>
> Very nice.
>
> Is it in the public domain? I don't see any copyright nor license
> mention in the source code...
>

Hello,

I am in final testing now, so feel free to download the static. It is
a pain in the but to compile (static is Linux). By the end of the week
it should be all pacakaged etc...

J

Gavin M. Roy wrote:

> This is very exciting, is this stable, production ready, etc?
>
> Gavin
>
> Alvaro Herrera wrote:
>
>> On Fri, Aug 01, 2003 at 05:06:00PM -0700, Joshua D. Drake wrote:
>>
>>
>>> Hello,
>>>
>>> As a recent flurry of activity has commenced within Command Prompt we
>>> have released
>>> upon this rather unround earth, plPHP. Yes it is trigger safe, yes
>>> you can write UDF's in
>>> PostgreSQL with PHP now.
>>>
>>
>>
>> Very nice.
>>
>> Is it in the public domain? I don't see any copyright nor license
>> mention in the source code...
>>
>>
>>
>
>

Uh, PHP isn't GPL, as of PHP4, http://www.php.net/license/

Q. Why is PHP 4 not dual-licensed under the GNU General Public License
(GPL) like PHP 3 was?

A. GPL enforces many restrictions on what can and cannot be done with
the licensed code. The PHP developers decided to release PHP under a
much more loose license (Apache-style), to help PHP become as popular as
possible.

I have attached the license that came with PHP 4.0.4.

---------------------------------------------------------------------------

Joshua D. Drake wrote:
> Hello,
>
> Well PHP is GPL... thus we left it GPL... it belongs to the
> community. Enjoy :)
>
> J
>
>
> Alvaro Herrera wrote:
> > On Fri, Aug 01, 2003 at 05:06:00PM -0700, Joshua D. Drake wrote:
> >
> >>Hello,
> >>
> >> As a recent flurry of activity has commenced within Command Prompt we
> >>have released
> >>upon this rather unround earth, plPHP. Yes it is trigger safe, yes you
> >>can write UDF's in
> >>PostgreSQL with PHP now.
> >
> >
> > Very nice.
> >
> > Is it in the public domain? I don't see any copyright nor license
> > mention in the source code...
> >
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>

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

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Uh, PHP isn't GPL, as of PHP4, http://www.php.net/license/

Consider also that if you have hopes of plPHP someday being included in
the standard Postgres distribution, it'll need to be BSD-licensed.

(Including PLs in the standard distro strikes me as a good idea, BTW.
They usually need maintenance along with the core backend code.)

regards, tom lane

On Fri, 1 Aug 2003, Joshua D. Drake wrote:

> I am in final testing now, so feel free to download the static. It is
> a pain in the but to compile (static is Linux). By the end of the week
> it should be all pacakaged etc...

Will this compile in any environment where PHP is installed?
ie. FreeBSD

>Will this compile in any environment where PHP is installed?
>ie. FreeBSD
>

Well it is only tested on Linux but there is no reason to think it
wouldn't compile on any unix that was gcc based.

Dear all
I was waiting for this type of product but will plPHP turn to be like LXP

also does it support all the PHP4 syntax

Regards,
V Kashyap

----- Original Message -----
From: "Francisco J Reyes" <fran(at)natserv(dot)net>
To: "Joshua D. Drake" <jd(at)commandprompt(dot)com>
Cc: "Gavin M. Roy" <gmr(at)bteg(dot)net>; <pgsql-general(at)postgresql(dot)org>
Sent: Sunday, August 03, 2003 00:04
Subject: Re: [GENERAL] plPHP -- sort of an announcement.. but not commercial

> On Fri, 1 Aug 2003, Joshua D. Drake wrote:
>
> > I am in final testing now, so feel free to download the static. It is
> > a pain in the but to compile (static is Linux). By the end of the week
> > it should be all pacakaged etc...
>
> Will this compile in any environment where PHP is installed?
> ie. FreeBSD
>
> ---------------------------(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
>

On Fri, 2003-08-01 at 21:08, Ron Johnson wrote:
> On Fri, 2003-08-01 at 19:06, Joshua D. Drake wrote:
> > Hello,
> >
> > As a recent flurry of activity has commenced within Command Prompt we
> > have released
> > upon this rather unround earth, plPHP. Yes it is trigger safe, yes you
> > can write UDF's in
> > PostgreSQL with PHP now.
> >
> > Find it here:
> >
> > http://www.commandprompt.com/entry.lxp?lxpe=260
>
> Is there a possibility of getting this in v7.5?

Heres the things I think would have to happen to put this in 7.5

1) Resolve license issues (not bsd licensed)
2) Integrate it into the postgresql build system so it can work on all
platforms.
3) Make it build against different versions of php
4) More people testing it in different situations.

FWIW I tried installing it on a system over the weekend, the trigger
feature seemed to work, and the complex array example function seemed to
work ok, but the basic simple echo example failed. I've subscribed to
the mailing lists, so we'll see if I can figure out where I went wrong.

Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

Any chance that PHP in safe mode meets our requirements for a trusted
language? It would be nice to have both php and phpu as two different
choices.

On Fri, 1 Aug 2003, Joshua D. Drake wrote:

> Hello,
>
> As a recent flurry of activity has commenced within Command Prompt we
> have released
> upon this rather unround earth, plPHP. Yes it is trigger safe, yes you
> can write UDF's in
> PostgreSQL with PHP now.
>
> Find it here:
>
> http://www.commandprompt.com/entry.lxp?lxpe=260
>
> Have a glorius weekend.
>
> Sincerely,
>
> Joshua D. Drake
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>

Robert Treat wrote:
> On Fri, 2003-08-01 at 21:08, Ron Johnson wrote:
>>Is there a possibility of getting this in v7.5?
>
> Heres the things I think would have to happen to put this in 7.5
>
> 1) Resolve license issues (not bsd licensed)
> 2) Integrate it into the postgresql build system so it can work on all
> platforms.
> 3) Make it build against different versions of php
> 4) More people testing it in different situations.

Here's my list.

Minor issues/ general code cleanup:
1. eliminate '//' style comments
2. fix indentation

More significant:
2. Add support for array conversion in-out
3. Add support for set-returning functions
4. Add support for argument/return-value polymorphism
5. Incorporate recent improvements in function caching (ala PL/pgSQL)
6. Add documentation
7. Add regression test support
8. Modify for new ereport syntax and nested error contexts

Most significant:
9. Use PHP embed API instead of the PHP CLI (command line interface)
10.Fix license

Joe

On Mon, 4 Aug 2003, Joe Conway wrote:

> Robert Treat wrote:
> > On Fri, 2003-08-01 at 21:08, Ron Johnson wrote:
> >>Is there a possibility of getting this in v7.5?
> >
> > Heres the things I think would have to happen to put this in 7.5
> >
> > 1) Resolve license issues (not bsd licensed)
> > 2) Integrate it into the postgresql build system so it can work on all
> > platforms.
> > 3) Make it build against different versions of php
> > 4) More people testing it in different situations.
>
> Here's my list.
>
> Minor issues/ general code cleanup:
> 1. eliminate '//' style comments
> 2. fix indentation
>
> More significant:
> 2. Add support for array conversion in-out
> 3. Add support for set-returning functions
> 4. Add support for argument/return-value polymorphism
> 5. Incorporate recent improvements in function caching (ala PL/pgSQL)
> 6. Add documentation
> 7. Add regression test support
> 8. Modify for new ereport syntax and nested error contexts
>
> Most significant:
> 9. Use PHP embed API instead of the PHP CLI (command line interface)
> 10.Fix license

Looking at the license for PHP found here:

http://www.php.net/license/3_0.txt

it would seem to be pretty much an apache style license that doesn't allow
you to relicense it without permission. but it looks BSD compatible.

scott.marlowe wrote:
>>10.Fix license
>
> Looking at the license for PHP found here:
>
> http://www.php.net/license/3_0.txt
>
> it would seem to be pretty much an apache style license that doesn't allow
> you to relicense it without permission. but it looks BSD compatible.
>
>

The issue was that plPHP as posted was claimed to be GPL, although there
isn't any notice at all in the source that I saw.

Does the PHP license require programs that dynamically link carry their
license, similar to GPL (I didn't get that impression)? If not, then
something like PL/PHP should be licensable under BSD.

Joe

On Mon, 4 Aug 2003, Joe Conway wrote:

> scott.marlowe wrote:
> >>10.Fix license
> >
> > Looking at the license for PHP found here:
> >
> > http://www.php.net/license/3_0.txt
> >
> > it would seem to be pretty much an apache style license that doesn't allow
> > you to relicense it without permission. but it looks BSD compatible.
>
> The issue was that plPHP as posted was claimed to be GPL, although there
> isn't any notice at all in the source that I saw.
>
> Does the PHP license require programs that dynamically link carry their
> license, similar to GPL (I didn't get that impression)? If not, then
> something like PL/PHP should be licensable under BSD.

Yeah, I'm pretty sure it's safe to link to. We could always as the PHP
guys themselves to be sure.

Hello,

How do you mean to be like LXP?

J

Aspire wrote:

> Dear all
> I was waiting for this type of product but will plPHP turn to be like LXP
>
> also does it support all the PHP4 syntax
>
> Regards,
> V Kashyap
>
>
>
> ----- Original Message -----
> From: "Francisco J Reyes" <fran(at)natserv(dot)net>
> To: "Joshua D. Drake" <jd(at)commandprompt(dot)com>
> Cc: "Gavin M. Roy" <gmr(at)bteg(dot)net>; <pgsql-general(at)postgresql(dot)org>
> Sent: Sunday, August 03, 2003 00:04
> Subject: Re: [GENERAL] plPHP -- sort of an announcement.. but not commercial
>
>
>
>>On Fri, 1 Aug 2003, Joshua D. Drake wrote:
>>
>>
>>>I am in final testing now, so feel free to download the static. It is
>>>a pain in the but to compile (static is Linux). By the end of the week
>>>it should be all pacakaged etc...
>>
>>Will this compile in any environment where PHP is installed?
>>ie. FreeBSD
>>
>>---------------------------(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
>>

>>>
>>>1) Resolve license issues (not bsd licensed)

We can make it any license we want... Right now it is PHP licensed just
because that is what seemed to make sense.

>>>2) Integrate it into the postgresql build system so it can work on all
>>>platforms.

That is up to the core.

>>>3) Make it build against different versions of php

We don't believe it should support ANYTHING but 4.3.2 or above.

>>>4) More people testing it in different situations.

Makes sense.

>>
>>Here's my list.
>>
>>Minor issues/ general code cleanup:
>>1. eliminate '//' style comments

Our programmers prefer // style comments.

>>More significant:
>>2. Add support for array conversion in-out
>>3. Add support for set-returning functions
>>4. Add support for argument/return-value polymorphism
>>5. Incorporate recent improvements in function caching (ala PL/pgSQL)
>>6. Add documentation
>>7. Add regression test support
>>8. Modify for new ereport syntax and nested error contexts

These are all good suggestions. Anybody want to help? plPHP was done
as a proof of concept more than anything else. We are concentrating
our efforts on other things.

>>
>>Most significant:
>>9. Use PHP embed API instead of the PHP CLI (command line interface)
>>10.Fix license
>
>
> Looking at the license for PHP found here:
>
> http://www.php.net/license/3_0.txt
>
> it would seem to be pretty much an apache style license that doesn't allow
> you to relicense it without permission. but it looks BSD compatible.
>
>
>
> ---------------------------(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

On Mon, 4 Aug 2003, Joshua D. Drake wrote:

> >>>2) Integrate it into the postgresql build system so it can work on all
> >>>platforms.
>
> That is up to the core.

Actually, not really ... with erserver, I pulled down the various build
files for the various platforms, so that *in theory* it will build under
anything that PostgreSQL supports ...

> >>>3) Make it build against different versions of php
>
> We don't believe it should support ANYTHING but 4.3.2 or above.

So, it builds against PHP5? :) Humor aside, though, I imagine there are a
fair # of ISPs out there that still haven't gone above 4.1 ... the latest
PgMarket "dev version" only just drop'd 4.0 support ...

On Mon, 4 Aug 2003, Sean Chittenden wrote:

> > > >>10.Fix license
> > > >
> > > > Looking at the license for PHP found here:
> > > >
> > > > http://www.php.net/license/3_0.txt
> > > >
> > > > it would seem to be pretty much an apache style license that doesn't allow
> > > > you to relicense it without permission. but it looks BSD compatible.
> > >
> > > The issue was that plPHP as posted was claimed to be GPL, although there
> > > isn't any notice at all in the source that I saw.
> > >
> > > Does the PHP license require programs that dynamically link carry
> > > their license, similar to GPL (I didn't get that impression)? If
> > > not, then something like PL/PHP should be licensable under BSD.
> >
> > Yeah, I'm pretty sure it's safe to link to. We could always as the
> > PHP guys themselves to be sure.
>
> I'm pretty sure that's not right. I'm no an FSF/GNU expert, but
> wasn't that the point of the LGPL? I don't think a BSDL bit of code
> can link with a GPL bit of code without making the BSDL code GPL'ed,
> but a BSDL bit of code linked with an LGPL .so is very kosher, and
> should be the discouraged minimum software requirement for contrib/
> inclusion, but even then, the plPHP bits are still basically under a
> GPL license that's non-viral (but only non-viral at runtime,
> distribution, and linking purposes). -sc

PHP is NOT GPLd. It's got a license much like the apache license.

There is no linking clause. The basics of it are:

-- maintain copyright notice, whether distributed in binary or source.
-- Don't use the PHP name to endorse stuff.
-- anything with PHP in the name needs they permission
-- Must contain acknowledgement and the web site address
-- No one other than the PHP Group has the right to modify the terms
applicable to covered code created under this License.

That last one basically means you can't relicense it.

> > >>10.Fix license
> > >
> > > Looking at the license for PHP found here:
> > >
> > > http://www.php.net/license/3_0.txt
> > >
> > > it would seem to be pretty much an apache style license that doesn't allow
> > > you to relicense it without permission. but it looks BSD compatible.
> >
> > The issue was that plPHP as posted was claimed to be GPL, although there
> > isn't any notice at all in the source that I saw.
> >
> > Does the PHP license require programs that dynamically link carry
> > their license, similar to GPL (I didn't get that impression)? If
> > not, then something like PL/PHP should be licensable under BSD.
>
> Yeah, I'm pretty sure it's safe to link to. We could always as the
> PHP guys themselves to be sure.

I'm pretty sure that's not right. I'm no an FSF/GNU expert, but
wasn't that the point of the LGPL? I don't think a BSDL bit of code
can link with a GPL bit of code without making the BSDL code GPL'ed,
but a BSDL bit of code linked with an LGPL .so is very kosher, and
should be the discouraged minimum software requirement for contrib/
inclusion, but even then, the plPHP bits are still basically under a
GPL license that's non-viral (but only non-viral at runtime,
distribution, and linking purposes). -sc

--
Sean Chittenden

Sean Chittenden wrote:
> I'm pretty sure that's not right. I'm no an FSF/GNU expert, but
> wasn't that the point of the LGPL? I don't think a BSDL bit of code
> can link with a GPL bit of code without making the BSDL code GPL'ed,

That's just it -- PHP is not under GPL.

Joe

> >I'm pretty sure that's not right. I'm no an FSF/GNU expert, but
> >wasn't that the point of the LGPL? I don't think a BSDL bit of
> >code can link with a GPL bit of code without making the BSDL code
> >GPL'ed,
>
> That's just it -- PHP is not under GPL.

*nods* I was clarifying that a GPL lib can't be linked with a non-GPL
bit of code w/o the non-GPL code becoming GPL, even though it doesn't
apply in this case, unless Command Prompt licenses their plPHP under
the GPL.

--
Sean Chittenden

On Mon, 4 Aug 2003, Joshua D. Drake wrote:

> > *nods* I was clarifying that a GPL lib can't be linked with a non-GPL
> > bit of code w/o the non-GPL code becoming GPL, even though it doesn't
> > apply in this case, unless Command Prompt licenses their plPHP under
> > the GPL.
>
> Were not going to license under the GPL. We did initially for a few
> brief minutes, because I was under the false impression that PHP was
> GPLd and I did not want to pay for the bandwidth for the insuing
> flameware if we didn't follow the GPL.
>
> We are not GPL fans by any means and that is why we relicensed under the
> PHP license. We are also no opposed to just giving it the standard BSD
> but the PHP license seemed to make sense.

Do we need official permission to call the language plPHP by the way?
That's the only part of the PHP license I'm wondering about.

> *nods* I was clarifying that a GPL lib can't be linked with a non-GPL
> bit of code w/o the non-GPL code becoming GPL, even though it doesn't
> apply in this case, unless Command Prompt licenses their plPHP under
> the GPL.

Were not going to license under the GPL. We did initially for a few
brief minutes, because I was under the false impression that PHP was
GPLd and I did not want to pay for the bandwidth for the insuing
flameware if we didn't follow the GPL.

We are not GPL fans by any means and that is why we relicensed under the
PHP license. We are also no opposed to just giving it the standard BSD
but the PHP license seemed to make sense.

Sincerely,

Joshua Drake

>

>
> Do we need official permission to call the language plPHP by the way?
> That's the only part of the PHP license I'm wondering about.

From what I read:

Products derived from this software may not be called "PHP", nor
may "PHP" appear in their name, without prior written permission
from group(at)php(dot)net(dot) You may indicate that your software works in
conjunction with PHP by saying "Foo for PHP" instead of calling
it "PHP Foo" or "phpfoo"

No. We don't need to do that. We couldn't call it PHP Procedural
Language but Procedural Language for PHP (plPHP) is ok.

Sincerely,

Joshua Drake

"Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> From what I read:
> Products derived from this software may not be called "PHP", nor
> may "PHP" appear in their name, without prior written permission
> from group(at)php(dot)net(dot) You may indicate that your software works in
> conjunction with PHP by saying "Foo for PHP" instead of calling
> it "PHP Foo" or "phpfoo"
> No. We don't need to do that. We couldn't call it PHP Procedural
> Language but Procedural Language for PHP (plPHP) is ok.

However, your code is not "derived from" PHP, is it? It's a glue layer
that allows PHP to be attached to Postgres (or vice versa if you prefer).
It's not clear to me that you're bound by any of their copyright
conditions, since you aren't planning to ship any of their code in your
tarball.

It'd probably be polite to contact them and let them know that you want
to call it plphp because "plfoo" is the standard name for a Postgres PL
based on language "foo". It's hard to believe that they'd object.

regards, tom lane

Tom Lane writes:

> (Including PLs in the standard distro strikes me as a good idea, BTW.
> They usually need maintenance along with the core backend code.)

We could also say that keeping some PLs outside the core would keep us
more honest in keeping the interfaces stable. The only maintenance that
PLs really need to get are global search-and-replace bug fixes and making
use of new server features.

Consider, we already have (at least) Ruby, Sh, R, and Java language
handlers out there, and we're not putting all of these in the core anytime
soon. The handlers we currently have in the core cover the most popular
languages, but there should be room for serious external development.

Btw., one concern I have about putting this PHP thing in the core is that
it would create a circular build dependency between PostgreSQL and PHP.

--
Peter Eisentraut peter_e(at)gmx(dot)net

On Tue, 5 Aug 2003, Peter Eisentraut wrote:

> Tom Lane writes:
>
> > (Including PLs in the standard distro strikes me as a good idea, BTW.
> > They usually need maintenance along with the core backend code.)
>
> We could also say that keeping some PLs outside the core would keep us
> more honest in keeping the interfaces stable. The only maintenance that
> PLs really need to get are global search-and-replace bug fixes and making
> use of new server features.
>
> Consider, we already have (at least) Ruby, Sh, R, and Java language
> handlers out there, and we're not putting all of these in the core anytime
> soon. The handlers we currently have in the core cover the most popular
> languages, but there should be room for serious external development.
>
> Btw., one concern I have about putting this PHP thing in the core is that
> it would create a circular build dependency between PostgreSQL and PHP.

Agreed. I still want to know if we can have "safe mode" enabled and make
a trusted / untrusted version. Is that workable? I would very much like
to have a trusted version.

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane writes:
>> (Including PLs in the standard distro strikes me as a good idea, BTW.
>> They usually need maintenance along with the core backend code.)

> We could also say that keeping some PLs outside the core would keep us
> more honest in keeping the interfaces stable.

If we had a carefully defined interface between PLs and the core, then
we might have some reason to think it'd stay stable. But we have no
defined API, and thus there is hardly any chance that PLs not maintained
with the core won't break. I'm certainly not willing to agree that
anything the existing PLs happen to depend upon is frozen.

> Btw., one concern I have about putting this PHP thing in the core is that
> it would create a circular build dependency between PostgreSQL and PHP.

Hmm, that could be a problem all right ...

regards, tom lane

scott.marlowe writes:

> Do we need official permission to call the language plPHP by the way?

Can someone explain to me why language handler modules for PostgreSQL are
always called "PL/Language"? Consider if someone wrote a language binding
for Scheme, then calling that "procedural language Scheme" sounds like an
insult to me.

--
Peter Eisentraut peter_e(at)gmx(dot)net

On Wed, 6 Aug 2003, Peter Eisentraut wrote:

> scott.marlowe writes:
>
> > Do we need official permission to call the language plPHP by the way?
>
> Can someone explain to me why language handler modules for PostgreSQL are
> always called "PL/Language"? Consider if someone wrote a language binding
> for Scheme, then calling that "procedural language Scheme" sounds like an
> insult to me.

vs calling them ... what? :)

For lack of any other suggestion, they are always called PL/Language?

On Fri, 1 Aug 2003, Joshua D. Drake wrote:

> Hello,
>
> As a recent flurry of activity has commenced within Command Prompt we
> have released
> upon this rather unround earth, plPHP. Yes it is trigger safe, yes you
> can write UDF's in
> PostgreSQL with PHP now.
>
> Find it here:
>
> http://www.commandprompt.com/entry.lxp?lxpe=260

I'm looking for how to reference old/new rows in a trigger, what's the
name of the data structure to use there? Thanks for doing this, by the
way to all the folks involved.

Hello,

I sent your request to the developers.

Joshua Drake

scott.marlowe wrote:

>On Fri, 1 Aug 2003, Joshua D. Drake wrote:
>
>
>
>>Hello,
>>
>> As a recent flurry of activity has commenced within Command Prompt we
>>have released
>>upon this rather unround earth, plPHP. Yes it is trigger safe, yes you
>>can write UDF's in
>>PostgreSQL with PHP now.
>>
>> Find it here:
>>
>> http://www.commandprompt.com/entry.lxp?lxpe=260
>>
>>
>
>I'm looking for how to reference old/new rows in a trigger, what's the
>name of the data structure to use there? Thanks for doing this, by the
>way to all the folks involved.
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faqs/FAQ.html
>
>