Ok, so you would like the code to not reset the interrupted exception so that when it returns the interrupted bit will still be set and you can check for isInterrupted ?
The SQL error is rather vague here since it is not really a SQL error, rather someone cancelled the thread.
+ Server PostgreSQL 9.1.9 on i686-pc-linux-gnu, compiled by gcc-4.4.real (Debian 4.4.5-8) 4.4.5, 32-bit
+ Error message / stack trace
org.postgresql.util.PSQLException: Beim Verbindungsversuch trat eine Unterbrechung auf. at org.postgresql.Driver$ConnectThread.getResult(Driver.java:365) at org.postgresql.Driver.connect(Driver.java:269) …
+ Description
Recently I discovered this problem because it prevents to tell other SQLExceptions and interruption apart (in the exception handlers). After examining the source of org.postgresql.Driver I noticed that org.postgresql.Driver$ConnectThread.getResult catches InterruptedException and throws a org.postgresql.util.PSQLException instead BUT without supplying the InterruptedException as the cause (exception chaining) and without resetting the interrupted flag via Thread.currentThread().interrupt() (SQL error code / SQL state is unspecific, too). Please note that this behavior is present in 9.2-1003, too.
Therefore I suggest that the handling of InterruptedException should be changed so it becomes more interoperable with client code that needs to handle SQLExceptions differently from thread interruption -- in a concurrent environment an already scheduled database query may become obsolete before it finishes because another query may be needed for example because of user intervention.
