[HACKERS] anoncvs failure...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Folks- Has the password for anoncvs been changed? I can't seem to get into it anymore. Virtually, Ned Wolpert [EMAIL PROTECTED] D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7q8XViysnOdCML0URArjBAJ9xkuFik8VWCALEMOFG4SUDDG3nlACfVa05 98136MftKgl9sp9pPXz7SlM= =zSvL -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: [JDBC] New backend functions?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sounds like there aren't objections to my requested function, get_last_returned_oid(). I'm going to work on the function call for postgres this weekend. Purpose: Retain the last oid returned (if any) in a variable associated with the connection on the backend, so the next request to the backend has access to it. It will be set when an insert or update is completed, so preparedStatements and stored procedures can use it. If I'm able to provide patches by Monday, and if it works fine (without causing general meltdowns :-) would this be able to be in the 7.2 beta, or will it need to be part of 7.3? (The answer to this question will help me decide on how much time I should spend on it this weekend.) On 23-Aug-2001 Tom Lane wrote: I assume this OID would be associated with a client connection. Is this going to work with client side connection pooling? Good point. Will this really get around the original poster's problem?? It must. If transactions are on, any pooling mechanism needs to continue to use that connection for the client unti the transaction is done. (Most require the client to either tell the pool manager the connection is no longer need, via a close() call, or a pool-manager specific call, precisely because the client needs it to complete the transaction. My feeling is that if this is a problem, then this method call may need to be limited to the transaction context, but I hope that this is not the case. Most pool managers (and I'm only speaking about Java here) require some activity on the client to give up the connection, either directly or indirectly. Virtually, Ned Wolpert [EMAIL PROTECTED] D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7hpkHiysnOdCML0URAhPnAJ9z/aWCR88kk60WmZJRalusOYm78ACeLPl7 jRlgOPLcuPd7JCsJy5JomUA= =ruJB -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: [JDBC] New backend functions? [was Re: JDBC ch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23-Aug-2001 Rene Pijlman wrote: What should the semantics be exactly? How about the multiple INSERT's i've been reading about on hackers? ... Only the OID of the last row inserted by the statement? How about an UPDATE statement that updates multiple rows? Well, here's my thoughts on this... The functionality would be that the very last inserted or updated OID would be stored in this static variable that is associated with the connection/session. So, in multiple inserts or updates, it is the last oid affect where this variable would be updated. How about triggers that insert/update extra rows? ... Only the OID of the row directly inserted by the client statement? It would be the last updated request caused by any insert or update, regardless of if its a trigger, preparedStatement, etc. How about Large Objects? Should inserting or updating a large object affect getLastInsertedOID()? Yes. I assume this OID would be associated with a client connection. Is this going to work with client side connection pooling? It must... that's the reason for this. Specifically, the JDBC driver has a method in it that is called getInsertedOID() which provides the last sucessfully inserted row's OID. This is specific to the driver, and JDBC pooling techniques do not allow access to this method. (It's not part of the JDBC spec) So, to make this data accessable to the users in a pooling condition, the call select getLastOID() needs to return the OID that is specific to the session. In Java, pooling techniques generally are aquired, then released, as dependant on the client or timeout procedures, and not randomly used for individual queries. (Mostly because of the need for the same driver during a transaction that takes multiple queries.) How about transaction semantics? INSERT row 1, Commit, INSERT row 2, Rollback... what should getLastInsertedOID() return? Can it, with a static variable? Good question. I'd start with rollback not affecting this value. Reason being that this function would be mostly used in a transaction anyways. I would not object to making this method only available during a transaction block if that helps. Virtually, Ned Wolpert [EMAIL PROTECTED] D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7hWEwiysnOdCML0URAk3xAJ92nYoy22mP4Yk8xk53vojlF42w5gCfbnZf uexoQ9yqexctXvQM0yx+g2Y= =yK6n -END PGP SIGNATURE- ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Re: [JDBC] New backend functions? [was Re: JDBC changes for 7.2.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I like your function name, get_last_returned_oid(). That works for me. On 23-Aug-2001 Tom Lane wrote: Ned Wolpert [EMAIL PROTECTED] writes: Should the backend support the function getLastInsertedOID() or even getLastInsertedPrimaryKey() (or both)? I don't think you have any chance of doing the latter --- for one thing, how are you going to declare that function's return type? But the former seems doable and reasonable to me: whenever an OID is returned to the client in an INSERT or UPDATE command result, also stash it in a static variable that can be picked up by this function. Please pick a more SQL-friendly (ie, case insensitive) naming convention, though. And note that it'd apply to both INSERT and UPDATE. Maybe get_last_returned_oid() ? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) Virtually, Ned Wolpert [EMAIL PROTECTED] D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7hWGbiysnOdCML0URAkqAAJ9Liv8VS+CPMYozG1q1tuy7vGLuEACfUJRM Hdbns8MxyOVgurx5ztV8YZU= =BbF3 -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: [JDBC] New backend functions? [was Re: JDBC ch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23-Aug-2001 Tom Lane wrote: I assume this OID would be associated with a client connection. Is this going to work with client side connection pooling? Good point. Will this really get around the original poster's problem?? It must. If transactions are on, any pooling mechanism needs to continue to use that connection for the client unti the transaction is done. (Most require the client to either tell the pool manager the connection is no longer need, via a close() call, or a pool-manager specific call, precisely because the client needs it to complete the transaction. My feeling is that if this is a problem, then this method call may need to be limited to the transaction context, but I hope that this is not the case. Most pool managers (and I'm only speaking about Java here) require some activity on the client to give up the connection, either directly or indirectly. Virtually, Ned Wolpert [EMAIL PROTECTED] D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7hYNRiysnOdCML0URAre3AJ94x/4mfeaJX3IQjRtyTWafeaR/BgCeIB4V liQyRjblBSuX38R0kq+NvVw= =ltfC -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.2 items
From: [EMAIL PROTECTED] Date: Fri, 11 May 2001 10:41:57 +1200 Here is a small list of big TODO items. I was wondering which ones people were thinking about for 7.2? The need for stored procedures that return a record set. This is required to migrate from MSSQL, Interbase and others. This is a commonly requested item. This would be very useful, as well as the RETURNING clause that is supported elsewhere with inserts. -- Virtually, Ned Wolpert [EMAIL PROTECTED] D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
