Thread: RE: [INTERFACES] JDBC - Numeric & Decimal handling in 6.5.3?
The 6.5.3 driver is infact the 6.5.2 driver, due to a problem I had with CVS at the time :-( Peter -- Peter Mount Enterprise Support Maidstone Borough Council Any views stated are my own, and not those of Maidstone Borough Council. -----Original Message----- From: Dave Del Signore [mailto:dave@narnia.toledo.oh.us] Sent: Saturday, February 19, 2000 7:25 PM To: pgsql-interfaces@postgresql.org Subject: [INTERFACES] JDBC - Numeric & Decimal handling in 6.5.3? Hi, I've noticed that the numeric/decimal handling in the stock 6.5.3 driver is still not functional. Is work in progress on this one? I think I've been able to patch the driver up to support these types. In addition, I've fixed some other unimplemented functions. I also moved a few functions from the ResultSetMetaData class to the Field class, as it seemed the more appropriate place for them, and so that I might cache some of the field's properties instead of doing lookups each time. This is the first time I've ever posted a patch to a major project. Please forgive me (and let me know) if I've committed any breaches of etiquette, or done anything else improperly. The patch is available at: http://www.narnia.toledo.oh.us/downloads/jdbc.patch.gz. The patch should be applied from the interfaces/jdbc directory. Here's a list of the things I've done: postgresql.jdbc[12].DatabaseMetaData.getColumns() fixed Numeric Size and Decimal Digits handling postgresql.jdbc[12].ResultSetMetaData.isCaseSensitive() added handling to return appropriate values for numeric & decimal types. postgresql.jdbc[12].ResultSetMetaData.isSigned() added handling to return appropriate values for numeric & decimal types. postgresql.jdbc[12].ResultSetMetaData.getPrecision() now returns postgresql.Field.getPrecision() postgresql.jdbc[12].ResultSetMetaData.getScale() now returns postgresql.Field.getScale() postgresql.jdbc[12].ResultSetMetaData.getTableName() now returns postgresql.Field.getTableName() postgresql.jdbc2.ResultSet.next() sets this_row to null when we've moved past the last row postgresql.jdbc2.ResultSet.afterLast() sets this_row to null and current_row to 1 past the last row's index postgresql.jdbc2.ResultSet.getBigDecimal(int column) returns the appropriate value. Currently does not force the scale to the value specified by the row's metadata. postgresql.jdbc2.ResultSet.getBigDecimal(String columnName) returns postgresql.jdbc2.ResultSet.getBigDecimal(int column) postgresql.jdbc2.ResultSet.isBeforeFirst() postgresql.jdbc2.ResultSet.isFirst() postgresql.jdbc2.ResultSet.isLast() postgresql.jdbc2.ResultSet.isAfterLast() returns the appropriate value, by comparing current_row to the size of the row array postgresql.Field.types[] added numeric and decimal postgresql.Field.typei[] added java.sql.Types.NUMERIC and DECIMAL postgresql.Field.typei[] postgresql.Field.getDetails() method to determine whether we've got the ResultSet's metadata cached, and get it if not. postgresql.Field.cacheDetails() method to query the field's metadata and cache the results postgresql.Field.getTableName() returns the field's table name. postgresql.Field.getAtttypmod() return the field's (postgresql) atttypmod property postgresql.Field.getScale() from ResultSetMetaData: return the field's scale, with handling for numerics & decimals postgresql.Field.getPrecision() from ResultSetMetaData: return the field's precision, with handling for numerics & decimals postgresql.ResultSet.getInt() abstract class to allow compilation ************
Sharing Database Connection Among Different CGI scripts writen in different languages
From
"Alexey V. Meledin"
Date:
Hi! I have 2 CGI scripts. Each script makes some queries to PostgreSQL and returns html code as a result . Simple example: 1-st CGI returns: "Hello, Anny!" (Anny is choosen from DataBase) 2-nd CGI returns: "There is 3 messages for you!" (nu,ber of messages is choosen from Database) Scripts can run separately each from other. Suppose, that I want to call 2-nd script from the first via HTTP or fork+execv+pipe. I receive: "Hello, Anny! There is 3 messages for you!" All OK, but I have two separated queries and two Backends started. It's not good, because I don't need any concurrency :( How can I optimize such situation? I see: 1. Share Database conection among two scripts. Can I do it? 2. Write "proxy" daemon to execute queries. Is it possible? 3. Use Application Servers and so either (can't use them and any other transaction mechanizm) Thenks, Alexey V. Meledin InterForge Developers Group, Saint-Petersburg look_to: <www.etcompany.ru><www.businessweb.ru> <www.inplan.spb.ru><www.pia.ru>>>>>>>>>>>>>>>>> mail_to: <avm@webclub.ru><nick_as: <cureman>>>>