Re: [JDBC] RE : ? (question mark) characters
the driver what character set the backend is sending us? Can't it ask the backend dynamically? This is what it actually does, isn't it? (Based on what I usually see in the trace output on the backend.) I tested a unicode database with varchar(255) fields and hungarian accented characters and it worked just fine. (With PostgreSQL 7.2.1 I think.) Peter ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[JDBC] JAVA vs PERL : PERL wins to postgreSQL
Hi, I ran a few bench marks on JAVA writing to a postgreSQL table using and found that for the same number of records added to the table as a similar PERL routine the following results : PERL 39 seconds : JAVA 45 Seconds. In a similar experiment where PERL and JAVA did treir output to the screen and not to a table, JAVA took 3 seconds and PERL 310 Seconds. My conclusion is that the database driver to postgreSQL is still far from efficient in the JAVA implementation. Both tests were run on the same computer. I would appreciate your comments and suggestions. Andy Sewell ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] ? (question mark) characters
On 02 Sep 2001 03:35:29 +0200, you wrote: You don't need multibyte for iso-8859-1. That's what I thought. But with current CVS (7.2) creating a database with -E LATIN1 fails without multibyte support. See the link in one of my previous postings in this thread. Regards, René Pijlman [EMAIL PROTECTED] ---(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] JAVA vs PERL : PERL wins to postgreSQL
I ran a few bench marks on JAVA writing to a postgreSQL table using and found that for the same number of records added to the table as a similar PERL routine the following results : PERL 39 seconds : JAVA 45 Seconds. In a similar experiment where PERL and JAVA did treir output to the screen and not to a table, JAVA took 3 seconds and PERL 310 Seconds. Was that 310 milliseconds in Perl? My conclusion is that the database driver to postgreSQL is still far from efficient in the JAVA implementation. One thing that may affect the Java performance when written out to the screen is the overhead of using System.out.println() calls as these are a call to native code and synchronized too for multithreaded output. Maybe if we can pump the test through a profiler and work out where the bulk of the Java operations are occurring for test 1. Regards, Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] JAVA vs PERL : PERL wins to postgreSQL
On Mon, 03 Sep 2001 07:47:29 +0200, you wrote: I ran a few bench marks on JAVA writing to a postgreSQL table using and found that for the same number of records added to the table as a similar PERL routine the following results : PERL 39 seconds : JAVA 45 Seconds. In a similar experiment where PERL and JAVA did treir output to the screen and not to a table, Can you tell us some more about the algorithm? Is it one process with one connection, or are you restarting the Java application many times? What are the queries it executes? Is autocommit on or off? What JDK/JRE did you use? I've heard that the IBM JDK performs well. It would be interesting to give it a try. Its a free download on http://www-106.ibm.com/developerworks/java/ Regards, René Pijlman [EMAIL PROTECTED] ---(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
[JDBC] SocketException on connect, busy server
Hi!
On a busy server, serving web pages using tomcat and apache, I
get this error sometimes:
java.net.SocketException: errno: 48, error: Address already in
use for fd: 168
at java.net.PlainSocketImpl.socketConnect(Native
Method)
at
java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java,
Compiled Code)
at
java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java,
Compiled Code)
at
java.net.PlainSocketImpl.connect(PlainSocketImpl.java, Compiled
Code)
at java.net.Socket.init(Socket.java, Compiled Code)
at java.net.Socket.init(Socket.java, Compiled Code)
at org.postgresql.PG_Stream.init(PG_Stream.java,
Compiled Code)
at
org.postgresql.Connection.openConnection(Connection.java,
Compiled Code)
at org.postgresql.Driver.connect(Driver.java, Compiled
Code)
at
java.sql.DriverManager.getConnection(DriverManager.java,
Compiled Code)
at
java.sql.DriverManager.getConnection(DriverManager.java,
Compiled Code)
at
net.pingpong.util.core.PPDbBroker.getConnection(PPDbBroker.java,
Compiled Code)
at
net.pingpong.util.core.PPGlobalDbBroker.getConnection(PPGlobalDbBroker.java,
Compiled Code)
at
net.pingpong.core.PPPerson.getDepartmentId(PPPerson.java,
Compiled Code)
at
pp.system.ppentrance._0002fpp_0002fsystem_0002fppentrance_0002fevents_0002dcatalog_0002ejspevents_0002dcatalog_jsp_0._jspService(_0002fpp_0002fsystem_0
002fppentrance_0002fevents_0002dcatalog_0002ejspevents_0002dcatalog_jsp_0.java,
Compiled Code)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java,
Compiled Code)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java,
Compiled Code)
at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java,
Compiled Code)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java,
Compiled Code)
at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java,
Compiled Code)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java,
Compiled Code)
at
org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java,
Compiled Code)
at org.apache.tomcat.core.Handler.service(Handler.java,
Compiled Code)
at
org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java,
Compiled Code)
at
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java,
Compiled Code)
at
org.apache.tomcat.core.ContextManager.service(ContextManager.java,
Compiled Code)
at
org.apache.tomcat.service.connector.Ajp12ConnectionHandler.processConnection(Ajp12ConnectionHandler.java,
Compiled Code)
at
org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java,
Compiled Code)
at
org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java,
Compiled Code)
at java.lang.Thread.run(Thread.java, Compiled Code)
End of Stack Trace
It happens around here in our app (in the database connection
broker):
synchronized (connections) {
if (connections.size() maxConnections) {
// All connections used but we can open a new one.
try {
con = DriverManager.getConnection(dbURL, DEFAULT_USER,
DEFAULT_PASSWD);
connections.put(con, new PPDbConnData(false, new Date()));
(connections is a Hash containing a number of db connections).
Hence, it seems to happen only when all connections are busy
and opening a new one is necessary. This seems to me like some
kind of synchronization problem, but I can't find it. Any
ideas?
/Palle
--
Partitur Informationsteknik AB
Wenner-Gren Center +46 8 566 280 02
113 46 Stockholm +46 70 785 86 02
Sweden [EMAIL PROTECTED]
---(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 : ? (question mark) characters
On Mon, 03 Sep 2001 09:49:27 -0700, you wrote: Yes this is exactly what the driver does. It asks the server what character set is being used for the database. Unfortunatly the server only knows about character sets if multibyte support is compiled in. If the server is compiled without multibyte, then it always reports to the client that the character set is SQL_ASCII (where SQL_ASCII is 7bit ascii). Thus if you don't have multibyte enabled on the server you can't support 8bit characters through the jdbc driver, unless you specifically tell the connection what character set to use (i.e. override the default obtained from the server). Excellent explanation, thanks. This would be great info for the FAQ. I've seen this issue appear three times or so in the relatively short time I'm on this list. Regards, René Pijlman [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [JDBC] RE : ? (question mark) characters
Kovács Péter wrote: the driver what character set the backend is sending us? Can't it ask the backend dynamically? This is what it actually does, isn't it? (Based on what I usually see in the trace output on the backend.) I tested a unicode database with varchar(255) fields and hungarian accented characters and it worked just fine. (With PostgreSQL 7.2.1 I think.) Yes this is exactly what the driver does. It asks the server what character set is being used for the database. Unfortunatly the server only knows about character sets if multibyte support is compiled in. If the server is compiled without multibyte, then it always reports to the client that the character set is SQL_ASCII (where SQL_ASCII is 7bit ascii). Thus if you don't have multibyte enabled on the server you can't support 8bit characters through the jdbc driver, unless you specifically tell the connection what character set to use (i.e. override the default obtained from the server). thanks, --Barry ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [JDBC] JAVA vs PERL : PERL wins to postgreSQL
On Mon, 3 Sep 2001, andy wrote: Hi, I ran a few bench marks on JAVA writing to a postgreSQL table using and found that for the same number of records added to the table as a similar PERL routine the following results : PERL 39 seconds : JAVA 45 Seconds. How did you start the tests? For Java to really show it's strengh it usually requires a few warm-up runs, so that the JIT or Hotspot optimizers get started. But I still wouldn't be surprised if perl was faster. I'm sure it's easier to write a DBI/DBD driver than a JDBC driver. /Anders _ A n d e r s B e n g t s s o n [EMAIL PROTECTED] Stockholm, Sweden _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [JDBC] JAVA vs PERL : PERL wins to postgreSQL
i have several questions about the benchmark run that all come down to one basic question - was the benchmark fair? 1) were you trying to test the performance of the languages or were you trying to test the performance of the drivers? if you are trying to test _languages_ then what you should do is to use a common driver. if you are coding on a windoze platform you can set up the odbc driver and have both perl and java connect to the db through the same driver. i don't know how 'fair' that test is though because java will still have the overhead of jdbc:odbc bridge. 2) assuming that you are trying to test differences in drivers, what did the tests consist of? were the insertions done in the context of a transaction or outside of one? a test that i ran that inserted 250+ records in one table and then 4500 in another test through perl and odbc ran at about 1:25 out of a transaction and 0:30 inside of a transaction. there's a big difference. 3) did both of the drivers used have the same settings? did you make sure that the autocommit states were identical? 4) did you take into account ONLY the amount of time needed to insert the data or were the times listed for assembling, inserting, and reporting results? 5) did you do a warm up session so that the code was in the same state as if it had been running on the server or were both run from cold starts? would that make a difference in terms of loading up all the drivers, etc.? 6) did the benchmark only use one connection for the entire test or were multiple connections used? if multiple, did you optimize your code like you would for a production setting where you would be using connection pooling? rjsjr -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of andy Sent: Monday, September 03, 2001 12:47 AM To: [EMAIL PROTECTED] Subject: [JDBC] JAVA vs PERL : PERL wins to postgreSQL Hi, I ran a few bench marks on JAVA writing to a postgreSQL table using and found that for the same number of records added to the table as a similar PERL routine the following results : PERL 39 seconds : JAVA 45 Seconds. In a similar experiment where PERL and JAVA did treir output to the screen and not to a table, JAVA took 3 seconds and PERL 310 Seconds. My conclusion is that the database driver to postgreSQL is still far from efficient in the JAVA implementation. Both tests were run on the same computer. I would appreciate your comments and suggestions. Andy Sewell ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[JDBC] PGpoint and PGcircle both sql type 1111?
I was wondering why it is that both PGpoint and PGcircle return a getColumnType of ? Is an arbirtrary number for non-JDBC-standard type? Or, could the PG extended types be differentiated somehow? (e.g. and 1112)? I am using the JBOSS ejb server, which makes use of the column type in order to figure out what to do with the columns, so it's important to me that they be differentiated. If this is easy to do, I may just patch the sources and submit my changes. But first I'd like to hear if anyone else out there has an opinion on this matter. Thanks, Bryan ---(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] Read transactions don't work on 7.0.x db's
Barry Lind [EMAIL PROTECTED] writes: The multiple statements in one call is there for performance reasons. Please don't remove it entirely since it works fine in 7.1 and 7.2. Instead your fix should be conditional based on server version: Given that someone else is proposing a patch that will break backward compatibility to 7.0 servers anyway, I'm unconvinced that we need this at all. Perhaps a discussion about the costs and benefits of backwards compatibility in the JDBC driver is needed --- what tradeoffs do people want to make? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [JDBC] Read transactions don't work on 7.0.x db's
From my POV there are two costs here: 1) The speed degradation by supporting multiple versions of postgres. I tend not to be too concerned by speed, and more concerned with ease of use. If speed really becomes an issue I can go into the code and remove the offending inefficiency caused by supporting multiple versions. 2) The barrier to entry by new jdbc, and postgres users trying to use postgres, and jdbc for the first time. If it doesn't work out of the box, then they will leave. I have a bias towards making it easier for people to use the software. However given the speed of server development. How far back are we going to support ? An argument can be made that since the software is free then there really is no reason not to upgrade. The biggest reason for me not to upgrade my server is reliability. What I have now works! I am hesitant to upgrade the server on a server which needs to run 24/7. That being said I am more likely to upgrade the jdbc driver, since: 1) it is really easy to back out the upgrade. 2) I have some ability to debug the jdbc driver and figure out what is going wrong. My ability to debug the postgres server is significantly less (approaching 0). So along with making it easier for new people to get the code up and running with a minimum of effort. I would like to take advantage of new jdbc features on older servers. My 2 cents worth Dave On Mon, 2001-09-03 at 19:46, Tom Lane wrote: Barry Lind [EMAIL PROTECTED] writes: The multiple statements in one call is there for performance reasons. Please don't remove it entirely since it works fine in 7.1 and 7.2. Instead your fix should be conditional based on server version: Given that someone else is proposing a patch that will break backward compatibility to 7.0 servers anyway, I'm unconvinced that we need this at all. Perhaps a discussion about the costs and benefits of backwards compatibility in the JDBC driver is needed --- what tradeoffs do people want to make? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [JDBC] Re: Unterminated quoted string error.
I have added a description to the CVS and it will appear in 7.2. It is in the development docs now. Hi Barry, I looked in the postgresql documentation and couldn't find any mention of a bytea type. Well actually, I found .. $ grep -i bytea * bki-commands.html:bytea/TT catalog-pg-proc.html:bytea/TT xfunc-c.html:bytea/TD xfunc-c.html:(bytea *)/TD but no real info on what it is, or no mention of it in the main types page. Anyway, I think I'm fine for now, stipping the null chars from my data. Tom. On Tue, Aug 28, 2001 at 09:17:19PM -0700, Barry Lind wrote: Thomas, The text datatypes in postgres (i.e. char, varchar, text) do not support storing null characters. If your data contains nulls then you need to use the binary datatype bytea. Unfortunately the JDBC drivers do not currently support the bytea datatype. thanks, --Barry Thomas O'Dowd wrote: I found problem. My string has a null character in the middle of it. I noticed from the Connection.java code that the null character idicates end of query so I guess that is what is happening. I'll strip out my null strings in the mean time as they are not needed before sending them to the driver but I'm wondering if the preparedStatement.setString() shouldn't escape nulls or something. It already escapes single quotes and backslashes. What do people think? Cheers, Tom. On Wed, Aug 29, 2001 at 08:53:31AM +0900, Thomas O'Dowd wrote: Thanks Barry, I turned on debugging in postgresql. I found that the query is being truncated and is not fully making it to the backend, therefore I'm getting the Unterminated string error. I'll have a look into why and report back if I find anything. Cheers, Tom. On Tue, Aug 28, 2001 at 12:56:50PM -0700, Barry Lind wrote: Thomas, If you turn on debug messages on the server to print out the SQL statements it receives you should be able to get the exact string that the server is receiving from the client and failing on. That might help you find the problem. thanks, --Barry Thomas O'Dowd wrote: Hi all, I'm currently chasing down a bug. Wonder if anyone can throw some light on it. I get the following exception. An I/O error has occured while flushing the output - Exception: java.io.IOException: Connection reset by peer Stack Trace: java.io.IOException: Connection reset by peer at java.net.SocketOutputStream.socketWrite(Native Method) at java.net.SocketOutputStream.write(SocketOutputStream.java:83) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:72) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:130) at org.postgresql.PG_Stream.flush(PG_Stream.java:414) at org.postgresql.Connection.ExecSQL(Connection.java:479) at org.postgresql.jdbc2.Statement.execute(Statement.java:294) at org.postgresql.jdbc2.Statement.executeUpdate(Statement.java:78) at org.postgresql.jdbc2.PreparedStatement.executeUpdate(PreparedStatement.java:122) And in the postgresql.log file I get... ERROR: Unterminated quoted string FATAL 1: Socket command type unknown But I'm pretty sure that my strings are quoted properly. That is to say that there are about 90 escaped single quotes in a string I'm inserting also though. Anyone seen this before? I'm currently using a version of the driver that I compiled from cvs on the 18th of Jun. Was anything patched since that might effect this? Anyway, I've been digging around for quite a while now so I thought I'd shoot the list a mail before going to bed. Tom. -- Thomas O'Dowd. - Nooping - http://nooper.com [EMAIL PROTECTED] - Testing - http://nooper.co.jp/labs ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Thomas O'Dowd. - Nooping - http://nooper.com [EMAIL PROTECTED] - Testing - http://nooper.co.jp/labs ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) -- 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 4: Don't 'kill -9' the postmaster
Re: [JDBC] Re: Unterminated quoted string error.
I heard it was fixed too but looking around, I found nothing. I added it tonight to the types section. Thomas, You are correct about the poor documentation for bytea. I hear this is fixed in 7.2 docs, but haven't verified. I learned about it myself by looking at the internal pg_* tables and seeing how they used it. I'm glad to hear that you have a workaround for your original issue. thanks, --Barry Thomas O'Dowd wrote: Hi Barry, I looked in the postgresql documentation and couldn't find any mention of a bytea type. Well actually, I found .. $ grep -i bytea * bki-commands.html:bytea/TT catalog-pg-proc.html:bytea/TT xfunc-c.html:bytea/TD xfunc-c.html:(bytea *)/TD but no real info on what it is, or no mention of it in the main types page. Anyway, I think I'm fine for now, stipping the null chars from my data. Tom. On Tue, Aug 28, 2001 at 09:17:19PM -0700, Barry Lind wrote: Thomas, The text datatypes in postgres (i.e. char, varchar, text) do not support storing null characters. If your data contains nulls then you need to use the binary datatype bytea. Unfortunately the JDBC drivers do not currently support the bytea datatype. thanks, --Barry Thomas O'Dowd wrote: I found problem. My string has a null character in the middle of it. I noticed from the Connection.java code that the null character idicates end of query so I guess that is what is happening. I'll strip out my null strings in the mean time as they are not needed before sending them to the driver but I'm wondering if the preparedStatement.setString() shouldn't escape nulls or something. It already escapes single quotes and backslashes. What do people think? Cheers, Tom. On Wed, Aug 29, 2001 at 08:53:31AM +0900, Thomas O'Dowd wrote: Thanks Barry, I turned on debugging in postgresql. I found that the query is being truncated and is not fully making it to the backend, therefore I'm getting the Unterminated string error. I'll have a look into why and report back if I find anything. Cheers, Tom. On Tue, Aug 28, 2001 at 12:56:50PM -0700, Barry Lind wrote: Thomas, If you turn on debug messages on the server to print out the SQL statements it receives you should be able to get the exact string that the server is receiving from the client and failing on. That might help you find the problem. thanks, --Barry Thomas O'Dowd wrote: Hi all, I'm currently chasing down a bug. Wonder if anyone can throw some light on it. I get the following exception. An I/O error has occured while flushing the output - Exception: java.io.IOException: Connection reset by peer Stack Trace: java.io.IOException: Connection reset by peer at java.net.SocketOutputStream.socketWrite(Native Method) at java.net.SocketOutputStream.write(SocketOutputStream.java:83) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:72) at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:130) at org.postgresql.PG_Stream.flush(PG_Stream.java:414) at org.postgresql.Connection.ExecSQL(Connection.java:479) at org.postgresql.jdbc2.Statement.execute(Statement.java:294) at org.postgresql.jdbc2.Statement.executeUpdate(Statement.java:78) at org.postgresql.jdbc2.PreparedStatement.executeUpdate(PreparedStatement.java:122) And in the postgresql.log file I get... ERROR: Unterminated quoted string FATAL 1: Socket command type unknown But I'm pretty sure that my strings are quoted properly. That is to say that there are about 90 escaped single quotes in a string I'm inserting also though. Anyone seen this before? I'm currently using a version of the driver that I compiled from cvs on the 18th of Jun. Was anything patched since that might effect this? Anyway, I've been digging around for quite a while now so I thought I'd shoot the list a mail before going to bed. Tom. -- Thomas O'Dowd. - Nooping - http://nooper.com [EMAIL PROTECTED] - Testing - http://nooper.co.jp/labs ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] ---(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 -- 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 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [JDBC] Read transactions don't work on 7.0.x db's
I think it is important to support backward compatibility in code like the JDBC driver. It is often the case that code opperates in an environment where there may be servers at different release levels (production databases on 7.0, while dev databases are on 7.1). Thus I think that maintaining backward compatibility to the previous release is a minimum requirement. Begining with the 7.2 JDBC code it is now possible to support backward compatibility (i.e. methods now exist to conditionally execute code based on server version). That wasn't the case before now. In fact the 7.1 JDBC code is not backward compatible with 7.0 (although the incompatibilies are in areas that many users may not notice and thus for many it is backwardly compatible). I am not sure how far back to maintain backward compatibility. I think it is dependent on how often new server versions are released. In general I would not want to force a database user to upgrade more than once per year (since doing a dump/restore on a large database can be a large hastle). Therefore I would recommend that going forward the JDBC drivers support all back releases that where the latest release within the last year. For example since 7.1 came out in April 2001, this would mean supporting 7.0 until April 2002. And if 7.2 when production in October 2001, then 7.1 should be supported until October 2002. thanks, --Barry Tom Lane wrote: Barry Lind [EMAIL PROTECTED] writes: The multiple statements in one call is there for performance reasons. Please don't remove it entirely since it works fine in 7.1 and 7.2. Instead your fix should be conditional based on server version: Given that someone else is proposing a patch that will break backward compatibility to 7.0 servers anyway, I'm unconvinced that we need this at all. Perhaps a discussion about the costs and benefits of backwards compatibility in the JDBC driver is needed --- what tradeoffs do people want to make? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
