php with postgres
-----Original Message-----
From: ivan [mailto:iv@psycho.pl]
Sent: 12 July 2003 22:34
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] php with postgreswhat do you think about plphp ?
I know a few people that would probably welcome it.
Regards, Dave.
Import Notes
Resolved by subject fallback
On Sat, 12 Jul 2003, Dave Page wrote:
-----Original Message-----
From: ivan [mailto:iv@psycho.pl]
Sent: 12 July 2003 22:34
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] php with postgreswhat do you think about plphp ?
I know a few people that would probably welcome it.
Regards, Dave.
ok, but php should build this lang for postgres i think
so, we should talk with php group ?
ivan wrote:
ok, but php should build this lang for postgres i think
so, we should talk with php group ?
I have been talking with several people about this on-and-off for a
while now. If I can find some time in the next few months, I will
probably write it (if no one beats me to it). I'm thinking that it
should be written using Postgres 7.5devel (once 7.4 stable is branched)
and PHP5 (which is in alpha/early-beta testing).
Joe
-----Original Message-----
From: ivan [mailto:iv@psycho.pl]
Sent: 12 July 2003 23:02
To: Dave Page
Cc: pgsql-hackers@postgresql.org
Subject: RE: [HACKERS] php with postgresok, but php should build this lang for postgres i think
so, we should talk with php group ?
I doubt they will do the work - you would have to (or persuade someone
else to).
Regards, Dave.
Import Notes
Resolved by subject fallback
Joe Conway wrote:
ivan wrote:
ok, but php should build this lang for postgres i think
so, we should talk with php group ?I have been talking with several people about this on-and-off for a
while now. If I can find some time in the next few months, I will
probably write it (if no one beats me to it). I'm thinking that it
should be written using Postgres 7.5devel (once 7.4 stable is branched)
and PHP5 (which is in alpha/early-beta testing).
I had been briefly talking with Marcus Boerger (included in CC) from the
PHP team about it. He knows the PHP5 SAPI embed well. Can you include
him into the team (if not already)?
From what I know about this SAPI I think the PL/Tcl implementation
would be a good point to start from, as it looks very similar with
respect to the possibilities.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
Jan Wieck wrote:
I had been briefly talking with Marcus Boerger (included in CC) from the
PHP team about it. He knows the PHP5 SAPI embed well. Can you include
him into the team (if not already)?
Sure!
From what I know about this SAPI I think the PL/Tcl implementation
would be a good point to start from, as it looks very similar with
respect to the possibilities.
I was going to start from PL/R, which is a descendent of PL/Tcl --
reason being, in PL/R I've already got SRF/table-function support and
polymorphic argument/return-type support working. Also, I've done a fair
amount of work to preserve arrays and composite types as they move
back-and-forth.
My plan is to add a few missing things to PL/R over the next couple (or
so) weeks, and then start PL/PHP from that:
1) Cache lookup based on function oid and argument signature ala the
patch I recently sent in (and improved by Tom) for PL/pgSQL -- this
is needed to properly support polymorphic arguments.
2) Trigger support -- just haven't needed this so far, but we'll want it
in PL/PHP, so I may as well add it to PL/R too.
3) Re-add nested error handling -- I removed this from PL/R early on
just to simplify life. Should be easy to drop back in.
I've read some examples posted regarding the PHP embed SAPI, and it
looks very similar to the R interpreter also. It should be fairly easy
to drop the PHP embed calls in for the libR calls. The bulk of the work
will be in modifying the data conversion functions that map Postgres
composite types and arrays to similar structures in PHP.
Help on the PHP side of things would be most appreciated, because that's
the part I'm least familiar with.
Joe
what aoubt stream ?
in plpgsql you can just write command INSERT ... or DELETE
if you want sht like this in php you need to correct zend i think .
in php all var is declared as variant type but we need look at realy type.
I have other view, to first write php interpreter to postgres, and then
write a translator, which translate plphp code to C code . I cound be only
a another way, to remember about speed (compiled code is always faster
then src ) . Php source will be to testing, and to relese will be option
to translate this src to C src and then compile it.
ps. there could be also interpreter with debug version and relese version
(without checking some things)
dont forget about default value of functions args !! :>
On Sun, 13 Jul 2003, Joe Conway wrote:
Show quoted text
Jan Wieck wrote:
I had been briefly talking with Marcus Boerger (included in CC) from the
PHP team about it. He knows the PHP5 SAPI embed well. Can you include
him into the team (if not already)?Sure!
From what I know about this SAPI I think the PL/Tcl implementation
would be a good point to start from, as it looks very similar with
respect to the possibilities.I was going to start from PL/R, which is a descendent of PL/Tcl --
reason being, in PL/R I've already got SRF/table-function support and
polymorphic argument/return-type support working. Also, I've done a fair
amount of work to preserve arrays and composite types as they move
back-and-forth.My plan is to add a few missing things to PL/R over the next couple (or
so) weeks, and then start PL/PHP from that:
1) Cache lookup based on function oid and argument signature ala the
patch I recently sent in (and improved by Tom) for PL/pgSQL -- this
is needed to properly support polymorphic arguments.
2) Trigger support -- just haven't needed this so far, but we'll want it
in PL/PHP, so I may as well add it to PL/R too.
3) Re-add nested error handling -- I removed this from PL/R early on
just to simplify life. Should be easy to drop back in.I've read some examples posted regarding the PHP embed SAPI, and it
looks very similar to the R interpreter also. It should be fairly easy
to drop the PHP embed calls in for the libR calls. The bulk of the work
will be in modifying the data conversion functions that map Postgres
composite types and arrays to similar structures in PHP.Help on the PHP side of things would be most appreciated, because that's
the part I'm least familiar with.Joe
Hello Jan,
Sunday, July 13, 2003, 1:22:09 PM, you wrote:
JW> Joe Conway wrote:
ivan wrote:
ok, but php should build this lang for postgres i think
so, we should talk with php group ?I have been talking with several people about this on-and-off for a
while now. If I can find some time in the next few months, I will
probably write it (if no one beats me to it). I'm thinking that it
should be written using Postgres 7.5devel (once 7.4 stable is branched)
and PHP5 (which is in alpha/early-beta testing).
JW> I had been briefly talking with Marcus Boerger (included in CC) from the
JW> PHP team about it. He knows the PHP5 SAPI embed well. Can you include
JW> him into the team (if not already)?
JW> From what I know about this SAPI I think the PL/Tcl implementation
JW> would be a good point to start from, as it looks very similar with
JW> respect to the possibilities.
JW> Jan
Hello all,
Nice to hear from you all :-)
I met Bruce during LinuxTag fair/conference here in germany and talked to him
about this plan. I subscribed to the essential mailing lists right now but i am
not yet a member of the postgres dev team. However i will give have a deeper look
during next weekend or the next week. So that i can tell more in a few days.
Apart from that you may bug me with postgres/php bugs since it seems i am
current php's ext/pgsql maintainer.
Best regards,
Marcus mailto:marcus.boerger@post.rwth-aachen.de
Hello ivan,
Sunday, July 13, 2003, 10:12:43 PM, you wrote:
i> what aoubt stream ?
i> in plpgsql you can just write command INSERT ... or DELETE
i> if you want sht like this in php you need to correct zend i think .
i> in php all var is declared as variant type but we need look at realy type.
In php we only have a few base types (int, float, bool, string) and some more
complex types like array and objects. The general idea is that at least the
base types can be converted without notice. This might be a problem when
integrating php into postgres but i guess everything can be solved the php
way. Since i also have zend commit rights i could fix things in this manner as
long as the language itself doesn't change in any way.
i> I have other view, to first write php interpreter to postgres, and then
i> write a translator, which translate plphp code to C code . I cound be only
i> a another way, to remember about speed (compiled code is always faster
i> then src ) . Php source will be to testing, and to relese will be option
i> to translate this src to C src and then compile it.
The general idea should be to leave php as is. That is, it is an interpreter.
During LT we were again able to speed it up very much. So performance
difference from interpreter to a real php to c compiler shouldn't be a problem
for the moment.
Also i thing when someone consideres using php inside his database he a) does
it because he doesn't know any other language or b) he uses very advanced
language features. In both cases the performance problem is no issue.
Additionally there are already tokenizers out which remove the
compile step. So atm we only can't get rid of the interpreter overhead.
Best regards,
Marcus mailto:marcus.boerger@post.rwth-aachen.de
Glad you got in touch with the right guys. Joe and Jan have both talked
about doing PlPHP for a while.
Marcus, would you check if PHP is using RESET ALL when passing
persistent connection to new clients? We added that capability a few
releases ago, specifically for PHP persistent connections, but I don't
think that ever got into the PHP code.
---------------------------------------------------------------------------
Marcus B?rger wrote:
Hello ivan,
Sunday, July 13, 2003, 10:12:43 PM, you wrote:
i> what aoubt stream ?
i> in plpgsql you can just write command INSERT ... or DELETE
i> if you want sht like this in php you need to correct zend i think .
i> in php all var is declared as variant type but we need look at realy type.In php we only have a few base types (int, float, bool, string) and some more
complex types like array and objects. The general idea is that at least the
base types can be converted without notice. This might be a problem when
integrating php into postgres but i guess everything can be solved the php
way. Since i also have zend commit rights i could fix things in this manner as
long as the language itself doesn't change in any way.i> I have other view, to first write php interpreter to postgres, and then
i> write a translator, which translate plphp code to C code . I cound be only
i> a another way, to remember about speed (compiled code is always faster
i> then src ) . Php source will be to testing, and to relese will be option
i> to translate this src to C src and then compile it.The general idea should be to leave php as is. That is, it is an interpreter.
During LT we were again able to speed it up very much. So performance
difference from interpreter to a real php to c compiler shouldn't be a problem
for the moment.
Also i thing when someone consideres using php inside his database he a) does
it because he doesn't know any other language or b) he uses very advanced
language features. In both cases the performance problem is no issue.
Additionally there are already tokenizers out which remove the
compile step. So atm we only can't get rid of the interpreter overhead.Best regards,
Marcus mailto:marcus.boerger@post.rwth-aachen.de---------------------------(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
--
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 19073Added to TODO:
o Add PL/PHP (Joe, Jan)
---------------------------------------------------------------------------
Joe Conway wrote:
Jan Wieck wrote:
I had been briefly talking with Marcus Boerger (included in CC) from the
PHP team about it. He knows the PHP5 SAPI embed well. Can you include
him into the team (if not already)?Sure!
From what I know about this SAPI I think the PL/Tcl implementation
would be a good point to start from, as it looks very similar with
respect to the possibilities.I was going to start from PL/R, which is a descendent of PL/Tcl --
reason being, in PL/R I've already got SRF/table-function support and
polymorphic argument/return-type support working. Also, I've done a fair
amount of work to preserve arrays and composite types as they move
back-and-forth.My plan is to add a few missing things to PL/R over the next couple (or
so) weeks, and then start PL/PHP from that:
1) Cache lookup based on function oid and argument signature ala the
patch I recently sent in (and improved by Tom) for PL/pgSQL -- this
is needed to properly support polymorphic arguments.
2) Trigger support -- just haven't needed this so far, but we'll want it
in PL/PHP, so I may as well add it to PL/R too.
3) Re-add nested error handling -- I removed this from PL/R early on
just to simplify life. Should be easy to drop back in.I've read some examples posted regarding the PHP embed SAPI, and it
looks very similar to the R interpreter also. It should be fairly easy
to drop the PHP embed calls in for the libR calls. The bulk of the work
will be in modifying the data conversion functions that map Postgres
composite types and arrays to similar structures in PHP.Help on the PHP side of things would be most appreciated, because that's
the part I'm least familiar with.Joe
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
--
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 19073Hello Bruce,
Monday, July 21, 2003, 9:15:05 PM, you wrote:
BM> Glad you got in touch with the right guys. Joe and Jan have both talked
BM> about doing PlPHP for a while.
:-)
BM> Marcus, would you check if PHP is using RESET ALL when passing
BM> persistent connection to new clients? We added that capability a few
BM> releases ago, specifically for PHP persistent connections, but I don't
BM> think that ever got into the PHP code.
Unfortunately we don't do so yet. Do i need to check for errors or can i do it
unconditionally on conenction start? And i'd need to know how to check if it
is available (like starting with which version).
Best regards,
Marcus mailto:marcus.boerger@post.rwth-aachen.de
Marcus B?rger wrote:
BM> Marcus, would you check if PHP is using RESET ALL when passing
BM> persistent connection to new clients? We added that capability a few
BM> releases ago, specifically for PHP persistent connections, but I don't
BM> think that ever got into the PHP code.Unfortunately we don't do so yet. Do i need to check for errors or can i do it
unconditionally on conenction start? And i'd need to know how to check if it
is available (like starting with which version).
It first appeared in PostgreSQL version 7.2. It doesn't generate any
failures. It just resets all SET settting to their defaults, in case
the previous client modified them.
--
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 19073Hello Bruce,
Monday, July 21, 2003, 9:37:08 PM, you wrote:
BM> Marcus B?rger wrote:
BM> Marcus, would you check if PHP is using RESET ALL when passing
BM> persistent connection to new clients? We added that capability a few
BM> releases ago, specifically for PHP persistent connections, but I don't
BM> think that ever got into the PHP code.Unfortunately we don't do so yet. Do i need to check for errors or can i do it
unconditionally on conenction start? And i'd need to know how to check if it
is available (like starting with which version).
BM> It first appeared in PostgreSQL version 7.2. It doesn't generate any
BM> failures. It just resets all SET settting to their defaults, in case
BM> the previous client modified them.
Committed for PHP 5.0 if there is a version 4.4 or 4.5 i'll commit the patch
for that version, too. Now we need someone with a big site to test whether it
brings any new problems. If there aren't problems i could probably also commit
to PHP 4.3.3. Btw. i don't do RESET ALL when creating the link because that
shouldn't be necessary.
--
Best regards,
Marcus mailto:marcus.boerger@post.rwth-aachen.de
Marcus B?rger wrote:
Hello Bruce,
Monday, July 21, 2003, 9:37:08 PM, you wrote:
BM> Marcus B?rger wrote:
BM> Marcus, would you check if PHP is using RESET ALL when passing
BM> persistent connection to new clients? We added that capability a few
BM> releases ago, specifically for PHP persistent connections, but I don't
BM> think that ever got into the PHP code.Unfortunately we don't do so yet. Do i need to check for errors or can i do it
unconditionally on conenction start? And i'd need to know how to check if it
is available (like starting with which version).BM> It first appeared in PostgreSQL version 7.2. It doesn't generate any
BM> failures. It just resets all SET settting to their defaults, in case
BM> the previous client modified them.Committed for PHP 5.0 if there is a version 4.4 or 4.5 i'll commit the patch
for that version, too. Now we need someone with a big site to test whether it
brings any new problems. If there aren't problems i could probably also commit
I think Theis originally complained about it, perhaps two years ago.
to PHP 4.3.3. Btw. i don't do RESET ALL when creating the link because that
shouldn't be necessary.
Right.
--
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
Help on the PHP side of things would be most appreciated, because that's
the part I'm least familiar with.
SAPI/Embed in PHP is very experimental which means that it can be molded to
suit PL/PHP needs. To my knowlege its only used as a plugin for irssi (irc
client which you can script using PHP), and a very poorly implemented MySQL
module.
Anyway if you need any help with it just shout :)
Edin
Bruce Momjian wrote:
Marcus B?rger wrote:
BM> Marcus, would you check if PHP is using RESET ALL when passing
BM> persistent connection to new clients? We added that capability a few
BM> releases ago, specifically for PHP persistent connections, but I don't
BM> think that ever got into the PHP code.Unfortunately we don't do so yet. Do i need to check for errors or can i do it
unconditionally on conenction start? And i'd need to know how to check if it
is available (like starting with which version).It first appeared in PostgreSQL version 7.2. It doesn't generate any
failures. It just resets all SET settting to their defaults, in case
the previous client modified them.
It does generate the usual error if the current transaction block is in
ABORT state. So the correct querystring to send would be something like
"ROLLBACK; RESET ALL"
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
Jan Wieck wrote:
Bruce Momjian wrote:
Marcus B?rger wrote:
BM> Marcus, would you check if PHP is using RESET ALL when passing
BM> persistent connection to new clients? We added that capability a few
BM> releases ago, specifically for PHP persistent connections, but I don't
BM> think that ever got into the PHP code.Unfortunately we don't do so yet. Do i need to check for errors or can i do it
unconditionally on conenction start? And i'd need to know how to check if it
is available (like starting with which version).It first appeared in PostgreSQL version 7.2. It doesn't generate any
failures. It just resets all SET settting to their defaults, in case
the previous client modified them.It does generate the usual error if the current transaction block is in
ABORT state. So the correct querystring to send would be something like"ROLLBACK; RESET ALL"
Oh, I remember that now as part of the persistent connection code. As I
remember, we told them to do BEGIN;COMMIT; to clear any open transaction
state passed to the new client. Is that in there? If not, it has to be
added too. ROLLBACK will generate an error if you are not in a
transaction, so it would fill the logs with errors.
--
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 19073Edin Kadribasic wrote:
Help on the PHP side of things would be most appreciated, because that's
the part I'm least familiar with.SAPI/Embed in PHP is very experimental which means that it can be molded to
suit PL/PHP needs. To my knowlege its only used as a plugin for irssi (irc
client which you can script using PHP), and a very poorly implemented MySQL
module.Anyway if you need any help with it just shout :)
Great! I'm likely to take you up on that before it's over ;-)
It will probably be a few more weeks before I can get started on this,
but it's definitely on my short list.
Joe
