Hello Bruce,
Thursday, July 31, 2003, 6:11:04 AM, you wrote:
BM Are you all done with the PHP persistent connection changes? Need any
BM help?
I think it's fine now (in PHP 5). We'll see how feedback is during the next
weeks.
Best regards,
Marcusmailto:[EMAIL
OK, can I see the new patches? I want to make sure everything is OK.
Thanks.
---
Marcus B?rger wrote:
Hello Bruce,
Thursday, July 31, 2003, 6:11:04 AM, you wrote:
BM Are you all done with the PHP persistent
Hello Bruce,
Thursday, July 24, 2003, 11:57:39 PM, you wrote:
BM Jan Wieck wrote:
Marcus B?rger wrote:
ATM i have a patch doing the following:
Connect:
If PQprotocolVersion() is available and = 3 PQparameterStatus() is available
then i check the server version. Else i check the lib
Hello Bruce,
Wednesday, July 23, 2003, 6:18:13 AM, you wrote:
BM Marcus B?rger wrote:
However it may be very usefull to terminate any open transaction before
reusing a persisten connection. Typically this happens when the same script
runs again. But anyway using transactions together with
Hello Bruce,
Thursday, July 24, 2003, 11:05:21 PM, you wrote:
BM Marcus B?rger wrote:
BM I don't see why you wouldn't just do BEGIN;COMMIT;RESET ALL; when you
BM pass the connection to a new client.
Bruce you said RESET ALL is available since 7.2. I am currently checking for
the
Are you all done with the PHP persistent connection changes? Need any
help?
---
Marcus B?rger wrote:
Hello Christopher,
Wednesday, July 23, 2003, 6:49:05 AM, you wrote:
Surely PHP can be modified so as to use the
OK, I checked the URL's, and I am a little confused. I don't understand
why the conditional transaction abort isn't in the same place as the
RESET ALL. Seems they should be done at the same time, though there is
an advantage to doing the RESET ALL during connect, because if someone
changes the
On Thu, Jul 24, 2003 at 05:52:07PM -0400, Bruce Momjian wrote:
Well, our behavior has always been to abort any open transctions on
client exit. In fact, it is so obvious, we don't even document it.
There are some SQL databases that commit on client exit, but that sounds
just wrong to us.
Marcus B?rger wrote:
BM I don't see why you wouldn't just do BEGIN;COMMIT;RESET ALL; when you
BM pass the connection to a new client.
Bruce you said RESET ALL is available since 7.2. I am currently checking for
the lib version but it would be more correct to check something on the
Marcus B?rger wrote:
BM I believe this should be BEGIN;ROLLBACK;RESET ALL; because our default
BM for a client that disconnects is to abort the transaction.
- If protocol version = 3 and transaction status == PQTRANS_IDLE:
RESET ALL;
- If protocol version = 3 and transaction
Marcus Börger wrote:
ATM i have a patch doing the following:
Connect:
If PQprotocolVersion() is available and = 3 PQparameterStatus() is available
then i check the server version. Else i check the lib version (*).
If the version to check is = 7.2 ido one of the following:
- If one of
Jan Wieck wrote:
Marcus B?rger wrote:
ATM i have a patch doing the following:
Connect:
If PQprotocolVersion() is available and = 3 PQparameterStatus() is available
then i check the server version. Else i check the lib version (*).
If the version to check is = 7.2 ido one of the
Marcus B?rger wrote:
BM Oh, I remember that now as part of the persistent connection code. As I
BM remember, we told them to do BEGIN;COMMIT; to clear any open transaction
BM state passed to the new client. Is that in there? If not, it has to be
BM added too. ROLLBACK will generate an
Marcus Börger wrote:
Here's the current log while reusing the persistent connection:
DEBUG: InitPostgres
DEBUG: StartTransactionCommand
DEBUG: query: select getdatabaseencoding()
DEBUG: ProcessQuery
DEBUG: CommitTransactionCommand
DEBUG: StartTransactionCommand
DEBUG: query: RESET ALL
On Mon, 21 Jul 2003, Bruce Momjian wrote:
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
scott.marlowe wrote:
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
On 7/22/2003 11:18 AM, scott.marlowe wrote:
On Mon, 21 Jul 2003, Bruce Momjian wrote:
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
Thomas Swan wrote:
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
Won't that break when we have nested transactions implemented? i.e.
begin;commit; would just open a sub transaction and have no effect on the
outer transaction...
Yes, it would break. I am not sure how we are going to flag that we
want to rollback all nested transactions, maybe
Yes, but you probably want old clients to be able to use the new nested
transaction code.
---
Rod Taylor wrote:
-- Start of PGP signed section.
Won't that break when we have nested transactions implemented? i.e.
Marcus B?rger wrote:
Yeah well it seems i gave a wrong impression what is actually happening now.
We don't handle any transaction at the moment but starting with the second
call to pg_pconnect on the same db we do RESET ALL. The following log is from
a three connections, so you can see two
Bruce Momjian wrote:
Marcus B?rger wrote:
However it may be very usefull to terminate any open transaction before
reusing a persisten connection. Typically this happens when the same script
runs again. But anyway using transactions together with persistent conenctions
in a multithreaded
Marcus B?rger wrote:
Hello Jan,
Tuesday, July 22, 2003, 10:57:56 PM, you wrote:
JW Bruce Momjian wrote:
Marcus B?rger wrote:
However it may be very usefull to terminate any open transaction before
reusing a persisten connection. Typically this happens when the same script
runs
DEBUG: InitPostgres
DEBUG: StartTransactionCommand
DEBUG: query: select getdatabaseencoding()
DEBUG: ProcessQuery
DEBUG: CommitTransactionCommand
DEBUG: StartTransactionCommand
DEBUG: query: RESET ALL
DEBUG: ProcessUtility: RESET ALL
DEBUG: CommitTransactionCommand
Hello Jan,
Tuesday, July 22, 2003, 10:57:56 PM, you wrote:
JW Bruce Momjian wrote:
Marcus B?rger wrote:
However it may be very usefull to terminate any open transaction before
reusing a persisten connection. Typically this happens when the same script
runs again. But anyway using
Hello Bruce,
Tuesday, July 22, 2003, 10:16:53 PM, you wrote:
BM Marcus B?rger wrote:
Yeah well it seems i gave a wrong impression what is actually happening now.
We don't handle any transaction at the moment but starting with the second
call to pg_pconnect on the same db we do RESET ALL. The
Hello Jan,
Tuesday, July 22, 2003, 1:28:18 PM, you wrote:
JW Marcus Börger wrote:
Here's the current log while reusing the persistent connection:
DEBUG: InitPostgres
DEBUG: StartTransactionCommand
DEBUG: query: select getdatabaseencoding()
DEBUG: ProcessQuery
DEBUG:
Hello Bruce,
Tuesday, July 22, 2003, 3:20:27 AM, you wrote:
BM 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,
Christopher Kings-Lynne wrote:
DEBUG: InitPostgres
DEBUG: StartTransactionCommand
DEBUG: query: select getdatabaseencoding()
DEBUG: ProcessQuery
DEBUG: CommitTransactionCommand
DEBUG: StartTransactionCommand
DEBUG: query: RESET ALL
DEBUG: ProcessUtility: RESET ALL
Marcus B?rger wrote:
However it may be very usefull to terminate any open transaction before
reusing a persisten connection. Typically this happens when the same script
runs again. But anyway using transactions together with persistent conenctions
in a multithreaded environment isn't the
Surely PHP can be modified so as to use the new 3.0 protocol feature to
detect whether it's in a transaction or not, so as to avoid unnecssary
querying?
Yes, you could, but it hardly seems worth it because they have to
support old and new protocols. Eventually, yes, they could use that
Added 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.
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,
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
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
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
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.
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
Edin 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
Hello 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
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
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
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
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
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
what do you think about plphp ?
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
-Original Message-
From: ivan [mailto:[EMAIL PROTECTED]
Sent: 12 July 2003 22:34
To: [EMAIL PROTECTED]
Subject: [HACKERS] php with postgres
what do you think about plphp ?
I know a few people that would probably welcome it.
Regards, Dave.
---(end
On Sat, 12 Jul 2003, Dave Page wrote:
-Original Message-
From: ivan [mailto:[EMAIL PROTECTED]
Sent: 12 July 2003 22:34
To: [EMAIL PROTECTED]
Subject: [HACKERS] php with postgres
what do you think about plphp ?
I know a few people that would probably welcome
-Original Message-
From: ivan [mailto:[EMAIL PROTECTED]
Sent: 12 July 2003 23:02
To: Dave Page
Cc: [EMAIL PROTECTED]
Subject: RE: [HACKERS] php with postgres
ok, but php should build this lang for postgres i think
so, we should talk with php group ?
I doubt they will do
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
50 matches
Mail list logo
