[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: [GENERAL] Comparing fixed precision to floating
FYI -- JDBC questions should go to the pgsql-jdbc mail list. As for your problem, I think probably the easiest workaround is to explicitly cast your constants. Assuming you are using PreparedStatements, a statement of the following form should work: select * from foo where bar = ?::numeric When the parameter is bound, the resulting statement sent to the server will be: select * from foo where bar = 123.456::numeric which should work correctly. thanks, --Barry Mike Finn wrote: I am using numeric(p,s) fields in a database schema. Using queries that contain a comparison like ... where numericField = 456.789 will generate an error Unable to identify an operator '=' for types 'numeric' and 'float8' You will have to retype this query using an explicit cast and if i explicitly cast the 456.789 (456.789::numeric) it does in fact work. But how do we get around this error when using JDBC? Shouldn't =(numeric, float8) be a standard operator in postgresql? My query is a dynamically prepared statement in java where many of the constant values are user supplied and poped into the statement via pstmt.setObject(pos, valueObj, type) in the case of a numeric field the type parameter is Types.NUMERIC and the valueObj parameter is a java.math.BigDecimal. (java.math.BigDecimal is the only way I know of to represent fixed precision and scale number in java). And of course this will blow with the previous error. I do have a work around which is to force the user supplied constant (a BigDecimal) to a string and user pstmt.setString(...). Effectively this create a clause of the form ... where numericField = '456.789' but it postgres will automatically cast the right hand side to a numeric I would have expected it to be able to cast a float8 constant to a numeric as well. If there is good reason why this can't be done, could someone explain what I am missing. Else could we put a =(numeric, float8) operator on the todo list? Thanks, in advance for any help. Mike. === Mike Finn Tactical Executive Systems [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[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: Couple of patches for jdbc driver
I agree with Bruce. I think we are in good shape for 7.2. As long as there is an active developer community working on maintaining and upgrading the code base there shouldn't be problems. Once we get the jdbc.postgresql.org website updated then there can be an official place to post patches/updated drivers on a more frequent schedule than the server patch releases if necessary. Although realistically the same level of control/caution should be used in accepting patches into the current release as there is being used for the rest of the product (i.e. it needs to be a high priority bug and a low risk fix to risk destabilizing a production set of code). Even in 7.1 there were some jdbc fixes that made it into 7.1.2, and quite frankly I haven't seen anything since 7.1.2 that I would have considered a candidate for patching into 7.1.3 based on the criteria I feel should be applied. The 7.1.2 driver is IMHO high quality, and I use it in production environments. Part of the problem I see is a too frequent habit of telling users on this list who are having problems simply to get the latest code from the truck. We should instead be telling them to get the latest released code ie. 7.1.2 or 7.1.3. thanks, --Barry Bruce Momjian wrote: * Barry Lind [EMAIL PROTECTED] wrote: | | | Now having said that, there isn't any reason that the jdbc code can't | be released more frequently than the server. But without a lot more Maybe there could be sub releases or something, e.g. jdbc version 7.1.2_004 begin release number 4 of the JDBC driver for 7.1.2. We can't keep recommending people to use CVS tip and if we cannot release a quality version of the driver synchronized with the release of the core server, then we will need another release cycle. 7.1.X was an aberation for jdbc because Peter Mount was unavailable and we didn't have jdbc people working on it yet. Let's see how 7.2 and 7.3 go with jdbc. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
RE: [JDBC] Re: Couple of patches for jdbc driver
The other reason for telling people who are experiencing problems with the driver to get the latest version is that their bug has probably already been fixed. However a certain degree of caution should probably be exercised here. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Bruce Momjian Sent: August 22, 2001 2:18 PM To: Barry Lind Cc: [EMAIL PROTECTED]; Gunnar Ronning Subject: Re: [JDBC] Re: Couple of patches for jdbc driver I agree with Bruce. I think we are in good shape for 7.2. As long as there is an active developer community working on maintaining and upgrading the code base there shouldn't be problems. Once we get the jdbc.postgresql.org website updated then there can be an official place to post patches/updated drivers on a more frequent schedule than the server patch releases if necessary. Although realistically the same level of control/caution should be used in accepting patches into the current release as there is being used for the rest of the product (i.e. it needs to be a high priority bug and a low risk fix to risk destabilizing a production set of code). Even in 7.1 there were some jdbc fixes that made it into 7.1.2, and quite frankly I haven't seen anything since 7.1.2 that I would have considered a candidate for patching into 7.1.3 based on the criteria I feel should be applied. The 7.1.2 driver is IMHO high quality, and I use it in production environments. Part of the problem I see is a too frequent habit of telling users on this list who are having problems simply to get the latest code from the truck. We should instead be telling them to get the latest released code ie. 7.1.2 or 7.1.3. Agreed. Part of the problem is that while 7.1.2 jdbc works well for most uses, it has some gaping holes especially with system catalog information, and there are so many that we just tell people to get the CVS version. -- 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] Re: Couple of patches for jdbc driver
The other reason for telling people who are experiencing problems with the driver to get the latest version is that their bug has probably already been fixed. However a certain degree of caution should probably be exercised here. The real problem is that I don't remember all the things we have fixed in jdbc since 7.1.2 version so I am telling people to get the CVS version even if I am not sure it is fixed in there. -- 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] jdbc proxy server ...
I've got a pile of RMI/JDBC code that does something damn close if not exactly what you want. Client server ends. I wrote it to allow interactive queries display the results in a Java applet or application then extended it to allow interactive and/or batch insert/update/delete functionality with (optionally) an email back telling you what happened to your batch SQL. It's known to work against Informix, Oracle 8i and I think PostgreSQL - certainly there's no reason why it won't asit just loads the appropriate JDBC driver. Email me if you're interested. Peter Wiley On Wed, 22 Aug 2001, Marc G. Fournier wrote: have a database behind a firewall ... we'd like to make connections available to that machine through a machine outside of the firewall, so that its a secure connection to the proxy, and in-secure from proxy-database ... the 'clients' will be written in java ... ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] jdbc proxy server ...
I don't mind. Wrote it to do one particular job, extended its functionality a couple times, most recently to implement a crude pooling system. The code needs work (what doesn't when it gets genericised... ) but it'd be a good starting point at least. I own the IP (as much as anyone owns IP to stuff built on top of other peoples' work) so there's no hassle releasing it as GPL code or whatever. I'm leaving this job in 2 weeks and going to another one so - how fast do you need the code? Another alternative for you is RmiJdbc. I looked at this but decided to 'roll my own' as I wanted the ability to submit batch jobs and do a couple other unusual things like crosstab datasets - in effect turn a 'deep' table structure into a 'wide' one for easy display in a JTable etc. The batch stuff is pretty generic but not the crosstab code; never needed to. something maybe that would fit into contrib? :) On Thu, 23 Aug 2001, Peter Wiley wrote: I've got a pile of RMI/JDBC code that does something damn close if not exactly what you want. Client server ends. I wrote it to allow interactive queries display the results in a Java applet or application then extended it to allow interactive and/or batch insert/update/delete functionality with (optionally) an email back telling you what happened to your batch SQL. It's known to work against Informix, Oracle 8i and I think PostgreSQL - certainly there's no reason why it won't asit just loads the appropriate JDBC driver. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
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]
