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 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 P
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
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 to
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 c
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 p
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
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 u
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
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 PQprotoc
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
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
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
> > 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 us
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
Christopher Kings-Lynne wrote:
> > > DEBUG: InitPostgres
> > > DEBUG: StartTransactionCommand
> > > DEBUG: query: select getdatabaseencoding()
> > > DEBUG: ProcessQuery
> > > DEBUG: CommitTransactionCommand
> > > DEBUG: StartTransactionCommand
> > > DEBUG: query: RESET ALL
> > > DEBUG: Proc
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> rel
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, 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
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
> > DEBUG: InitPostgres
> > DEBUG: StartTransactionCommand
> > DEBUG: query: select getdatabaseencoding()
> > DEBUG: ProcessQuery
> > DEBUG: CommitTransactionCommand
> > DEBUG: StartTransactionCommand
> > DEBUG: query: RESET ALL
> > DEBUG: ProcessUtility: RESET ALL
> > DEBUG: CommitTransac
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 scr
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 environment
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
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.
> >
> > 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, may
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 i
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 c
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
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, speci
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
DEBUG
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,
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
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 you
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
> >
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
> 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 PH
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, specific
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.
>
> Unfort
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, b
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
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
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
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
wri
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
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
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
> -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 s
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 d
> -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
what do you think about plphp ?
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
51 matches
Mail list logo
