Re: [PHP-DEV] TSRM compatibility note

2001-07-30 Thread Jouni Ahto



On Mon, 30 Jul 2001, Zeev Suraski wrote:

 We should probably change ext_skel to generate new-style fetches and 
 macros, so that new extensions take advantage of the faster approach.

Ok. Will fix later this week. Have to first catch up on what this actually
means. (I lost my home connection to the net at the beginning of April,
haven't followed most of the discussion going on, got a new connection 12
days ago, and now gone through mails to 3. July...)

-- Jouni



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Re: [INTERFACES] Re: PostgreSQL and PHP persistentconnections

2001-02-12 Thread Jouni Ahto

Any reasons there could't be either more statuses for a connection besides
CONNECTION_BAD, CONNECTION_OK, or alternativetely, a new libpq function
that could tell us READY_TO_RECEIVE_MORE_SQL_COMMANDS,
PREVIOUS_TRANSACTION_ABORTED_UNTIL_..., etc. (Sorry that I'm shouting... I
just write constant names that way like everyone else.)

-- Jouni

On Mon, 12 Feb 2001, Bruce Momjian wrote:

   We discussed using 'ROLLBACK' before passing a connection to a new user,
   but the problem was that ROLLBACK with no open transaction causes a
   server log error message.  We discussed adding 'ROLLBACK SILENT' to fix
   this, but I believe a better, more portable solution is a simple "BEGIN
   WORK;ROLLBACK".  This will do nothing if there is no open transaction,
   and will ROLLBACK any open transaction.  I propose this be sent by PHP
   as the first query when passing persistent connections.
  
  i'll have a look at that tomorrow (if my family allows;-). if
  "BEGIN WORK;ROLLBACK" does not stack transactions i think you
  might have found the solution to the php-postgres problem! do
 
 If we every get nested transactions, this will no longer work, but we
 don't have them, and will not for a while.
 
  you know how other script-interfaces (perl) to postgres
  handle the very same thing?
 
 They don't handle them, but our Java interface just added this feature.
 
 
   As far as SET changes, does anyone on the PostgreSQL interfaces list
   have a suggestion on how to RESET all session parameters?  Seems we may
   need to add this feature in to the backend.
  
  with the oracle driver (i wrote) there is a neat thing in the
  oci-libs: you have a server-handle _and_ a session handle.
  the session handle sits "on" the server-handle and keeps
  _all_ session specific data, the server handle "only" carries
  the pure connection to oracle. so i keep the server handle
  persistent and allocate/free session handles on it for each
  request to PHP. that way the sessions are always clean. but i
  also do a forces rollback on the session handle before i free
  it on request-end so that in case of a script error all
  outstanding transactions are rolled-back.
 
 Yes, it would be nice if we had that feature.
 
 -- 
   Bruce Momjian|  http://candle.pha.pa.us
   [EMAIL PROTECTED]   |  (610) 853-3000
   +  If your life is a hard drive, |  830 Blythe Avenue
   +  Christ can be your backup.|  Drexel Hill, Pennsylvania 19026
 
 -- 
 PHP Development Mailing List http://www.php.net/
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 To contact the list administrators, e-mail: [EMAIL PROTECTED]
 


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]