[JDBC] Re: JDBC changes for 7.2... some questions...
Ned, I would only agree to this functionality if it where a backend function. By putting it in the front end, you now need to front end to understand the special function. (And then you we are likely going to have requests that this special function be available in all the front ends JDBC, ODBC, perl, etc.). For the front end to understand the function it needs to parse the SQL statement. Thus under your proposal every select statement needs to be parsed to see if one of the selected items is the special function. I strive to ensure that the jdbc code does not need to parse the SQL statements and understand the grammer of the SQL language. Since functions can appear in select lists, where clauses, orderbys, and even insert and update statements, you quickly end up with the client needing to reimplement the entire parser that is already in the backend. You could argue that this really could be special cased (i.e. it must be exactly 'select getInsertedOID()' case and whitespace makes a difference, but then all you really have is a kludge for a specific problem, not a framework to solve other similar problems. I would argue that a framework does exist to solve this and other problems and that framework is to add additional functions into the backend. Given that the JDBC driver already does provide the information via the getLastOID() method, we are really dealing with a small isolated problem here because of the use of a connection pool that doesn't let you get at that method. (Unfortunatly for you, it is the problem you are facing). In general I don't think the benefits of this feature (i.e. providing information that is currently available, except when using certain 3rd party connection pooling mechanisms) are worth the long term costs. If the function was implemented in the backend, I think it would be a good idea. thanks, --Barry Ned Wolpert wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Actually, it's not a new function on the server... I'm just trying to find a way to access the getInsertedOID() method in the statement object without having direct access to the statement object. (My use-case is when the JDBC driver is wrapped in a pooling manager, like PoolMan, it wraps all classes.) I wanted to catch the line 'select @@last_oid' which would return a result set with the single entry based on the results of the method call 'getInsertedOID' but some people didn't like the syntax. So, I'm seaking comments to see if there is a better syntax people like, as long as they don't mind the functionality. One option is the 'faking' of the function call on the server, which really isn't a good option in itself, but outside of my original 'catch' line, its all I got. What's your thoughts? Do you see the need for the functionality? Do you have a solution that I need? On 22-Aug-2001 Barry Lind wrote: I am assuming that this would be a new function in the server. Therefore this wouldn't be jdbc specific and would be available to all client interfaces. I don't see what this really has to do with JDBC. thanks, --Barry Ned Wolpert wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ok, so you're not opposed to the idea then, just the syntax. Does anyone oppose having this concept in the JDBC driver? And what syntax is acceptable? Could we just do 'select getInsertedOID()' which would break people who have functions called getInsertedOID() of course... On 21-Aug-2001 Tom Lane wrote: Ned Wolpert [EMAIL PROTECTED] writes: What about the 'select @@last_oid' to make the getInsertedOID() call available even when the driver is wrapped by a pooling manager? How do people feel about this? Yech. At least, not with *that* syntax. @@ is a valid operator name in Postgres. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html 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 iD8DBQE7gv5yiysnOdCML0URAq7qAJkBRhAcE9wctn7bUAv7UMwN3n9+nwCeJR4V ymYTw8l3f9WU4V5idFsibAE= =UQ2M -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]) 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 iD8DBQE7g+agiysnOdCML0URAvbvAJ9GO/spmwQYZessjk4IenhtPuguSwCdHRQN xH+tnGqKpmg/UOSnxOevek0= =pcr+ -END PGP SIGNATURE- ---(end of
[JDBC] Re: JDBC changes for 7.2... some questions...
I am assuming that this would be a new function in the server. Therefore this wouldn't be jdbc specific and would be available to all client interfaces. I don't see what this really has to do with JDBC. thanks, --Barry Ned Wolpert wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ok, so you're not opposed to the idea then, just the syntax. Does anyone oppose having this concept in the JDBC driver? And what syntax is acceptable? Could we just do 'select getInsertedOID()' which would break people who have functions called getInsertedOID() of course... On 21-Aug-2001 Tom Lane wrote: Ned Wolpert [EMAIL PROTECTED] writes: What about the 'select @@last_oid' to make the getInsertedOID() call available even when the driver is wrapped by a pooling manager? How do people feel about this? Yech. At least, not with *that* syntax. @@ is a valid operator name in Postgres. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html 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 iD8DBQE7gv5yiysnOdCML0URAq7qAJkBRhAcE9wctn7bUAv7UMwN3n9+nwCeJR4V ymYTw8l3f9WU4V5idFsibAE= =UQ2M -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]) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[JDBC] Re: JDBC changes for 7.2... some questions...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Actually, it's not a new function on the server... I'm just trying to find a way to access the getInsertedOID() method in the statement object without having direct access to the statement object. (My use-case is when the JDBC driver is wrapped in a pooling manager, like PoolMan, it wraps all classes.) I wanted to catch the line 'select @@last_oid' which would return a result set with the single entry based on the results of the method call 'getInsertedOID' but some people didn't like the syntax. So, I'm seaking comments to see if there is a better syntax people like, as long as they don't mind the functionality. One option is the 'faking' of the function call on the server, which really isn't a good option in itself, but outside of my original 'catch' line, its all I got. What's your thoughts? Do you see the need for the functionality? Do you have a solution that I need? On 22-Aug-2001 Barry Lind wrote: I am assuming that this would be a new function in the server. Therefore this wouldn't be jdbc specific and would be available to all client interfaces. I don't see what this really has to do with JDBC. thanks, --Barry Ned Wolpert wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ok, so you're not opposed to the idea then, just the syntax. Does anyone oppose having this concept in the JDBC driver? And what syntax is acceptable? Could we just do 'select getInsertedOID()' which would break people who have functions called getInsertedOID() of course... On 21-Aug-2001 Tom Lane wrote: Ned Wolpert [EMAIL PROTECTED] writes: What about the 'select @@last_oid' to make the getInsertedOID() call available even when the driver is wrapped by a pooling manager? How do people feel about this? Yech. At least, not with *that* syntax. @@ is a valid operator name in Postgres. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html 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 iD8DBQE7gv5yiysnOdCML0URAq7qAJkBRhAcE9wctn7bUAv7UMwN3n9+nwCeJR4V ymYTw8l3f9WU4V5idFsibAE= =UQ2M -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]) 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 iD8DBQE7g+agiysnOdCML0URAvbvAJ9GO/spmwQYZessjk4IenhtPuguSwCdHRQN xH+tnGqKpmg/UOSnxOevek0= =pcr+ -END PGP SIGNATURE- ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] Re: JDBC changes for 7.2... some questions...
What's your thoughts? Do you see the need for the functionality? Do you have a solution that I need? Definitely need the functionality. It's one of the things holding up me porting an Informix system. Laziness is a bigger holdup of course - the Informix system is so bulletproof and I'm slowly re-writing all the 4GL in Java. FWIW, Informix returns the new SERIAL value through a structure SQLCA.SQLERRD[3] from memory. Not applicable to a PostgreSQL solution I'd say. On 22-Aug-2001 Barry Lind wrote: I am assuming that this would be a new function in the server. Therefore this wouldn't be jdbc specific and would be available to all client interfaces. I don't see what this really has to do with JDBC. thanks, --Barry Ned Wolpert wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ok, so you're not opposed to the idea then, just the syntax. Does anyone oppose having this concept in the JDBC driver? And what syntax is acceptable? Could we just do 'select getInsertedOID()' which would break people who have functions called getInsertedOID() of course... On 21-Aug-2001 Tom Lane wrote: Ned Wolpert [EMAIL PROTECTED] writes: What about the 'select @@last_oid' to make the getInsertedOID() call available even when the driver is wrapped by a pooling manager? How do people feel about this? Yech. At least, not with *that* syntax. @@ is a valid operator name in Postgres. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html 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 iD8DBQE7gv5yiysnOdCML0URAq7qAJkBRhAcE9wctn7bUAv7UMwN3n9+nwCeJR4V ymYTw8l3f9WU4V5idFsibAE= =UQ2M -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]) 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 iD8DBQE7g+agiysnOdCML0URAvbvAJ9GO/spmwQYZessjk4IenhtPuguSwCdHRQN xH+tnGqKpmg/UOSnxOevek0= =pcr+ -END PGP SIGNATURE- ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
