Обсуждение: Bug report: NullPointerException from Driver.connect when passed a Properties with non-string values

I found this while working with another JDBC driver (Stels XML driver).  The Postgresql driver's connect() method is
expectingthe passed Properties object to have only string values, but this is not actually guaranteed to be the case.
Ithink that the PG driver should wrap the NullPointerException in a SQLException, which would allow the DriverManager
toattempt to use other JDBC drivers to make the connection. 

Here is a simple Java program which will reproduce the problem:

==================
import java.sql.DriverManager;
import java.util.Properties;

public class PGTest {
    public static void main(String[] args) throws Exception {
        Class.forName("org.postgresql.Driver");
        Properties info = new Properties();
        info.put("foo", new Object());      // info.getPropert("foo") will return null
        DriverManager.getConnection("foo:bar//baz", info);
    }
}
==================

and here is the stack trace produced by running that program:

==================
Exception in thread "main" java.lang.NullPointerException
    at java.util.Hashtable.put(Hashtable.java:542)
    at java.util.Properties.setProperty(Properties.java:161)
    at org.postgresql.Driver.connect(Driver.java:244)
    at java.sql.DriverManager.getConnection(DriverManager.java:579)
    at java.sql.DriverManager.getConnection(DriverManager.java:190)
    at PGTest.main(PGTest.java:9)
==================

I'm using postgresql-9.2-1002.jdbc4.jar, with Java 7, running on Mac OS 10.8.2.  Output of java -version:
java version "1.7.0_07"
Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)

Hello Nathaniel,

Any very robust program will try to handle anything the user throws at it.

In this case you have passed a null value as an argument to the method
and it as acted according by giving you a NUllPointerException. Perhaps
wrapping this as SQLException may be more easily caught by your app., but
would be deceptive in response.

Perhaps you could submit a patch for consideration, to the solution you
desire. The code may be obtained at GitHub.

git clone git://github.com/pgjdbc/pgjdbc.git

danap.


Nathaniel Waisbrot wrote:
> I found this while working with another JDBC driver (Stels XML driver).  The Postgresql driver's connect() method is
expectingthe passed Properties object to have only string values, but this is not actually guaranteed to be the case.
Ithink that the PG driver should wrap the NullPointerException in a SQLException, which would allow the DriverManager
toattempt to use other JDBC drivers to make the connection. 
>
> Here is a simple Java program which will reproduce the problem:
>
> ==================
> import java.sql.DriverManager;
> import java.util.Properties;
>
> public class PGTest {
>     public static void main(String[] args) throws Exception {
>         Class.forName("org.postgresql.Driver");
>         Properties info = new Properties();
>         info.put("foo", new Object());      // info.getPropert("foo") will return null
>         DriverManager.getConnection("foo:bar//baz", info);
>     }
> }
> ==================
>
> and here is the stack trace produced by running that program:
>
> ==================
> Exception in thread "main" java.lang.NullPointerException
>     at java.util.Hashtable.put(Hashtable.java:542)
>     at java.util.Properties.setProperty(Properties.java:161)
>     at org.postgresql.Driver.connect(Driver.java:244)
>     at java.sql.DriverManager.getConnection(DriverManager.java:579)
>     at java.sql.DriverManager.getConnection(DriverManager.java:190)
>     at PGTest.main(PGTest.java:9)
> ==================
>
> I'm using postgresql-9.2-1002.jdbc4.jar, with Java 7, running on Mac OS 10.8.2.  Output of java -version:
> java version "1.7.0_07"
> Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
> Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)
>
>
>

Thanks for the responses, dmp and Dave.
I agree that it's rather surprising to be getting non-String values for the Driver, but I don't think it's actually
*required*by any spec that they be Strings.  The references I'm looking at are: 

The connect method of Driver, which takes a Properties:
http://docs.oracle.com/javase/6/docs/api/java/sql/Driver.html#connect%28java.lang.String,%20java.util.Properties%29

The Properties class:
http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html

Which warns that:
    "Because Properties inherits from Hashtable, the put and putAll methods can be applied to a Properties object.
Theiruse is strongly discouraged as they allow the caller to insert entries whose keys or values are not Strings. The
setPropertymethod should be used instead. If the store or save method is called on a "compromised" Properties object
thatcontains a non-String key or value, the call will fail. Similarly, the call to the propertyNames or list method
willfail if it is called on a "compromised" Properties object that contains a non-String key." 


Frustratingly, you need to actually look at the source code of Properties to see some undocumented behavior of
getProperty:

    public String getProperty(String key) {
        Object oval = super.get(key);
        String sval = (oval instanceof String) ? (String)oval : null;
        return ((sval == null) && (defaults != null)) ? defaults.getProperty(key) : sval;
    }


Note that middle line--the reason that my example program fails is because an Object is not of type String, and so
getPropertyis substituting a null value. 

I've attached a candidate patch for you: waisbrot-exception.patch checks the result of getProperty() and throws a
PSQLExceptionif it is null.  This allows drivers that want to deal with non-string Properties to get a turn with the
URL,but will cause DriverManager to report the error if no Driver can perform the connection.  







On Jan 28, 2013, at 1:40 PM, Dave Cramer <pg@fastcrypt.com> wrote:

> Well ... another interesting stretching of the spec.
>
> Driver PropertyInfo values are required to be Strings as per the spec.
http://docs.oracle.com/javase/1.3/docs/api/java/sql/DriverPropertyInfo.html
>
> Your test case is actually a bit misleading as getProperty returns null because getString on the empty object returns
null.
>
> while I'm inclined to accept a patch to fix this, this is clearly 'out of spec'
>
> Dave Cramer
>
> dave.cramer(at)credativ(dot)ca
> http://www.credativ.ca
>
>
> On Mon, Jan 28, 2013 at 1:16 PM, dmp <danap@ttc-cmc.net> wrote:
> Hello Nathaniel,
>
> Any very robust program will try to handle anything the user throws at it.
>
> In this case you have passed a null value as an argument to the method
> and it as acted according by giving you a NUllPointerException. Perhaps
> wrapping this as SQLException may be more easily caught by your app., but
> would be deceptive in response.
>
> Perhaps you could submit a patch for consideration, to the solution you
> desire. The code may be obtained at GitHub.
>
> git clone git://github.com/pgjdbc/pgjdbc.git
>
> danap.
>
>
>
> Nathaniel Waisbrot wrote:
> I found this while working with another JDBC driver (Stels XML driver).  The Postgresql driver's connect() method is
expectingthe passed Properties object to have only string values, but this is not actually guaranteed to be the case.
Ithink that the PG driver should wrap the NullPointerException in a SQLException, which would allow the DriverManager
toattempt to use other JDBC drivers to make the connection. 
>
> Here is a simple Java program which will reproduce the problem:
>
> ==================
> import java.sql.DriverManager;
> import java.util.Properties;
>
> public class PGTest {
>         public static void main(String[] args) throws Exception {
>                 Class.forName("org.postgresql.Driver");
>                 Properties info = new Properties();
>                 info.put("foo", new Object());      // info.getPropert("foo") will return null
>                 DriverManager.getConnection("foo:bar//baz", info);
>         }
> }
> ==================
>
> and here is the stack trace produced by running that program:
>
> ==================
> Exception in thread "main" java.lang.NullPointerException
>         at java.util.Hashtable.put(Hashtable.java:542)
>         at java.util.Properties.setProperty(Properties.java:161)
>         at org.postgresql.Driver.connect(Driver.java:244)
>         at java.sql.DriverManager.getConnection(DriverManager.java:579)
>         at java.sql.DriverManager.getConnection(DriverManager.java:190)
>         at PGTest.main(PGTest.java:9)
> ==================
>
> I'm using postgresql-9.2-1002.jdbc4.jar, with Java 7, running on Mac OS 10.8.2.  Output of java -version:
> java version "1.7.0_07"
> Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
> Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)
>
>
>
>
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
>

Nathaniel Waisbrot <waisbrot@highfleet.com> wrote:

> I found this while working with another JDBC driver (Stels XML
> driver).  The Postgresql driver's connect() method is expecting
> the passed Properties object to have only string values, but this
> is not actually guaranteed to be the case.

In addition to Dave's perfectly valid point about
DriverPropertyInfo, please note the following about the Properties
class:

http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html

This page includes:

| Each key and its corresponding value in the property list is a
| string.

and:

| Because Properties inherits from Hashtable, the put and putAll
| methods can be applied to a Properties object. Their use is
| strongly discouraged as they allow the caller to insert entries
| whose keys or values are not Strings. The setProperty method
| should be used instead. If the store or save method is called on
| a "compromised" Properties object that contains a non-String key
| or value, the call will fail. Similarly, the call to the
| propertyNames or list method will fail if it is called on a
| "compromised" Properties object that contains a non-String key.

So, while it is true that the Properties object is not guaranteed
to contain only String objects, doing otherwise is "strongly
discouraged", a Properties object containing other objects is
considered "compromised", and some methods which are part of the
Properties class will fail.  I think it is best for a JDBC driver
to throw an exception when it encounters such compromised objects.

> I think that the PG driver should wrap the NullPointerException
> in a SQLException, which would allow the DriverManager to attempt
> to use other JDBC drivers to make the connection.

Well, it should not normally be the properties which determine
which driver can be used for the connection, but the front of the
URL.  If it is the wrong driver, it should not throw any exception
at all; it should return NULL:

http://docs.oracle.com/javase/1.3/docs/api/java/sql/Driver.html#connect%28java.lang.String,%20java.util.Properties%29

| The driver should return "null" if it realizes it is the wrong
| kind of driver to connect to the given URL. This will be common,
| as when the JDBC driver manager is asked to connect to a given
| URL it passes the URL to each loaded driver in turn.
|
| The driver should raise a SQLException if it is the right driver
| to connect to the given URL, but has trouble connecting to the
| database.

But I do agree that it is bad form to allow a RuntimeException to
be thrown by a driver method rather than catching that and wrapping
it in a SQLException or returning null.

-Kevin

Hello Nathaniel,

Please check your patch again. I may be wrong, but I do not think that is going
to do it. According to your original stack trace the NULL error pointer occurs
at:

org.postgresql.Driver.connect(Driver.java:244)
String propName = (String)e.nextElement();

Kevin Grittner wrote:
> But I do agree that it is bad form to allow a RuntimeException to
> be thrown by a driver method rather than catching that and wrapping
> it in a SQLException or returning null.

This is probably the best approach for a patch.

danap.


Nathaniel Waisbrot wrote:
> Thanks for the responses, dmp and Dave.
> I agree that it's rather surprising to be getting non-String values for the Driver, but I don't think it's actually
*required*by any spec that they be Strings.  The references I'm looking at are: 
>
> The connect method of Driver, which takes a Properties:
> http://docs.oracle.com/javase/6/docs/api/java/sql/Driver.html#connect%28java.lang.String,%20java.util.Properties%29
>
> The Properties class:
> http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html
>
> Which warns that:
>      "Because Properties inherits from Hashtable, the put and putAll methods can be applied to a Properties object.
Theiruse is strongly discouraged as they allow the caller to insert entries whose keys or values are not Strings. The
setPropertymethod should be used instead. If the store or save method is called on a "compromised" Properties object
thatcontains a non-String key or value, the call will fail. Similarly, the call to the propertyNames or list method
willfail if it is called on a "compromised" Properties object that contains a non-String key." 
>
>
> Frustratingly, you need to actually look at the source code of Properties to see some undocumented behavior of
getProperty:
>
>      public String getProperty(String key) {
>          Object oval = super.get(key);
>          String sval = (oval instanceof String) ? (String)oval : null;
>          return ((sval == null)&&  (defaults != null)) ? defaults.getProperty(key) : sval;
>      }
>
>
> Note that middle line--the reason that my example program fails is because an Object is not of type String, and so
getPropertyis substituting a null value. 
>
> I've attached a candidate patch for you: waisbrot-exception.patch checks the result of getProperty() and throws a
PSQLExceptionif it is null.  This allows drivers that want to deal with non-string Properties to get a turn with the
URL,but will cause DriverManager to report the error if no Driver can perform the connection. 
>
>
>
> On Jan 28, 2013, at 1:40 PM, Dave Cramer<pg@fastcrypt.com>  wrote:
>
>> Well ... another interesting stretching of the spec.
>>
>> Driver PropertyInfo values are required to be Strings as per the spec.
http://docs.oracle.com/javase/1.3/docs/api/java/sql/DriverPropertyInfo.html
>>
>> Your test case is actually a bit misleading as getProperty returns null because getString on the empty object
returnsnull. 
>>
>> while I'm inclined to accept a patch to fix this, this is clearly 'out of spec'
>>
>> Dave Cramer
>>
>> dave.cramer(at)credativ(dot)ca
>> http://www.credativ.ca
>>
>>
>> On Mon, Jan 28, 2013 at 1:16 PM, dmp<danap@ttc-cmc.net>  wrote:
>> Hello Nathaniel,
>>
>> Any very robust program will try to handle anything the user throws at it.
>>
>> In this case you have passed a null value as an argument to the method
>> and it as acted according by giving you a NUllPointerException. Perhaps
>> wrapping this as SQLException may be more easily caught by your app., but
>> would be deceptive in response.
>>
>> Perhaps you could submit a patch for consideration, to the solution you
>> desire. The code may be obtained at GitHub.
>>
>> git clone git://github.com/pgjdbc/pgjdbc.git
>>
>> danap.
>>
>>
>>
>> Nathaniel Waisbrot wrote:
>> I found this while working with another JDBC driver (Stels XML driver).  The Postgresql driver's connect() method is
expectingthe passed Properties object to have only string values, but this is not actually guaranteed to be the case.
Ithink that the PG driver should wrap the NullPointerException in a SQLException, which would allow the DriverManager
toattempt to use other JDBC drivers to make the connection. 
>>
>> Here is a simple Java program which will reproduce the problem:
>>
>> ==================
>> import java.sql.DriverManager;
>> import java.util.Properties;
>>
>> public class PGTest {
>>          public static void main(String[] args) throws Exception {
>>                  Class.forName("org.postgresql.Driver");
>>                  Properties info = new Properties();
>>                  info.put("foo", new Object());      // info.getPropert("foo") will return null
>>                  DriverManager.getConnection("foo:bar//baz", info);
>>          }
>> }
>> ==================
>>
>> and here is the stack trace produced by running that program:
>>
>> ==================
>> Exception in thread "main" java.lang.NullPointerException
>>          at java.util.Hashtable.put(Hashtable.java:542)
>>          at java.util.Properties.setProperty(Properties.java:161)
>>          at org.postgresql.Driver.connect(Driver.java:244)
>>          at java.sql.DriverManager.getConnection(DriverManager.java:579)
>>          at java.sql.DriverManager.getConnection(DriverManager.java:190)
>>          at PGTest.main(PGTest.java:9)
>> ==================
>>
>> I'm using postgresql-9.2-1002.jdbc4.jar, with Java 7, running on Mac OS 10.8.2.  Output of java -version:
>> java version "1.7.0_07"
>> Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
>> Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)
>>
>>
>>
>>
>>
>>
>> --
>> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-jdbc

The line numbers on my original bug report might not match the latest from the repository.  I was working off of
9.2-1002.jdbc4

The null I see comes from the line

    props.setProperty(propName, info.getProperty(propName));

This is because info.getProperty(propName) returns null.  The current code expects that this can never happen, because
propNameis known to be a valid key and Hashtable cannot have null values.  However, as I pointed out, there's some
undocumentedbehavior in getProperty.  If you put a non-String value in (which it asks you to please not do), then
getPropertywill return "null" for any key associated with a non-String value. 



On Jan 28, 2013, at 3:19 PM, dmp <danap@ttc-cmc.net> wrote:

> Hello Nathaniel,
>
> Please check your patch again. I may be wrong, but I do not think that is going to do it. According to your original
stacktrace the NULL error pointer occurs 
> at:
>
> org.postgresql.Driver.connect(Driver.java:244)
> String propName = (String)e.nextElement();
>
> Kevin Grittner wrote:
>> But I do agree that it is bad form to allow a RuntimeException to
>> be thrown by a driver method rather than catching that and wrapping
>> it in a SQLException or returning null.
>
> This is probably the best approach for a patch.
>
> danap.
>
>
> Nathaniel Waisbrot wrote:
>> Thanks for the responses, dmp and Dave.
>> I agree that it's rather surprising to be getting non-String values for the Driver, but I don't think it's actually
*required*by any spec that they be Strings.  The references I'm looking at are: 
>>
>> The connect method of Driver, which takes a Properties:
>> http://docs.oracle.com/javase/6/docs/api/java/sql/Driver.html#connect%28java.lang.String,%20java.util.Properties%29
>>
>> The Properties class:
>> http://docs.oracle.com/javase/6/docs/api/java/util/Properties.html
>>
>> Which warns that:
>>     "Because Properties inherits from Hashtable, the put and putAll methods can be applied to a Properties object.
Theiruse is strongly discouraged as they allow the caller to insert entries whose keys or values are not Strings. The
setPropertymethod should be used instead. If the store or save method is called on a "compromised" Properties object
thatcontains a non-String key or value, the call will fail. Similarly, the call to the propertyNames or list method
willfail if it is called on a "compromised" Properties object that contains a non-String key." 
>>
>>
>> Frustratingly, you need to actually look at the source code of Properties to see some undocumented behavior of
getProperty:
>>
>>     public String getProperty(String key) {
>>         Object oval = super.get(key);
>>         String sval = (oval instanceof String) ? (String)oval : null;
>>         return ((sval == null)&&  (defaults != null)) ? defaults.getProperty(key) : sval;
>>     }
>>
>>
>> Note that middle line--the reason that my example program fails is because an Object is not of type String, and so
getPropertyis substituting a null value. 
>>
>> I've attached a candidate patch for you: waisbrot-exception.patch checks the result of getProperty() and throws a
PSQLExceptionif it is null.  This allows drivers that want to deal with non-string Properties to get a turn with the
URL,but will cause DriverManager to report the error if no Driver can perform the connection. 
>>
>>
>>
>> On Jan 28, 2013, at 1:40 PM, Dave Cramer<pg@fastcrypt.com>  wrote:
>>
>>> Well ... another interesting stretching of the spec.
>>>
>>> Driver PropertyInfo values are required to be Strings as per the spec.
http://docs.oracle.com/javase/1.3/docs/api/java/sql/DriverPropertyInfo.html
>>>
>>> Your test case is actually a bit misleading as getProperty returns null because getString on the empty object
returnsnull. 
>>>
>>> while I'm inclined to accept a patch to fix this, this is clearly 'out of spec'
>>>
>>> Dave Cramer
>>>
>>> dave.cramer(at)credativ(dot)ca
>>> http://www.credativ.ca
>>>
>>>
>>> On Mon, Jan 28, 2013 at 1:16 PM, dmp<danap@ttc-cmc.net>  wrote:
>>> Hello Nathaniel,
>>>
>>> Any very robust program will try to handle anything the user throws at it.
>>>
>>> In this case you have passed a null value as an argument to the method
>>> and it as acted according by giving you a NUllPointerException. Perhaps
>>> wrapping this as SQLException may be more easily caught by your app., but
>>> would be deceptive in response.
>>>
>>> Perhaps you could submit a patch for consideration, to the solution you
>>> desire. The code may be obtained at GitHub.
>>>
>>> git clone git://github.com/pgjdbc/pgjdbc.git
>>>
>>> danap.
>>>
>>>
>>>
>>> Nathaniel Waisbrot wrote:
>>> I found this while working with another JDBC driver (Stels XML driver).  The Postgresql driver's connect() method
isexpecting the passed Properties object to have only string values, but this is not actually guaranteed to be the
case. I think that the PG driver should wrap the NullPointerException in a SQLException, which would allow the
DriverManagerto attempt to use other JDBC drivers to make the connection. 
>>>
>>> Here is a simple Java program which will reproduce the problem:
>>>
>>> ==================
>>> import java.sql.DriverManager;
>>> import java.util.Properties;
>>>
>>> public class PGTest {
>>>         public static void main(String[] args) throws Exception {
>>>                 Class.forName("org.postgresql.Driver");
>>>                 Properties info = new Properties();
>>>                 info.put("foo", new Object());      // info.getPropert("foo") will return null
>>>                 DriverManager.getConnection("foo:bar//baz", info);
>>>         }
>>> }
>>> ==================
>>>
>>> and here is the stack trace produced by running that program:
>>>
>>> ==================
>>> Exception in thread "main" java.lang.NullPointerException
>>>         at java.util.Hashtable.put(Hashtable.java:542)
>>>         at java.util.Properties.setProperty(Properties.java:161)
>>>         at org.postgresql.Driver.connect(Driver.java:244)
>>>         at java.sql.DriverManager.getConnection(DriverManager.java:579)
>>>         at java.sql.DriverManager.getConnection(DriverManager.java:190)
>>>         at PGTest.main(PGTest.java:9)
>>> ==================
>>>
>>> I'm using postgresql-9.2-1002.jdbc4.jar, with Java 7, running on Mac OS 10.8.2.  Output of java -version:
>>> java version "1.7.0_07"
>>> Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
>>> Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
>>> To make changes to your subscription:
>>> http://www.postgresql.org/mailpref/pgsql-jdbc
>

Nathaniel patch should be fine. I think you have to test the properties Dave
as he has done. Its just a matter if you want it the SQLException or return
NULL.

Did you test this Nathaniel?

danap.

Dave Cramer wrote:
> My proposed patch is this
>
> if (url.startsWith("jdbc:postgresql:")) {
>              return null;
>          }
> Right at the top of getConnection, before we do any real work.
>
> Thoughts ?
>
> Dave Cramer
>
> dave.cramer(at)credativ(dot)ca
> http://www.credativ.ca

Dave Cramer <pg@fastcrypt.com> wrote:

> My proposed patch is this
>
>
> if (url.startsWith("jdbc:postgresql:")) {
>     return null;
> }
>
> Right at the top of getConnection, before we do any real work.
>
>
> Thoughts ?

Shouldn't that have a bang to reverse the logic?

-Kevin

I think that is what threw me. You are still going to need to
have Nathaniel's patch in case someone does try to throw in a bogus
properties that ends up null even thought the url is correct.

danap.

Kevin Grittner wrote:
> Dave Cramer<pg@fastcrypt.com>  wrote:
>
>> My proposed patch is this
>>
>>
>> if (url.startsWith("jdbc:postgresql:")) {
>>       return null;
>> }
>>
>> Right at the top of getConnection, before we do any real work.
>>
>>
>> Thoughts ?
>
> Shouldn't that have a bang to reverse the logic?
>
> -Kevin

I understand. Better also thow in:

if (info != null)
{
    for (Enumeration e = info.propertyNames(); e.hasMoreElements();)
         {
             String propName = (String)e.nextElement();
             props.setProperty(propName, info.getProperty(propName));
         }
}

and Nathaniel's patch. With yours, the above, and Nathaniel's that
should cover everything I think.

danap.


Dave Cramer wrote:
> it irks me to have to do that, as the java api for getProperty suggests
> that you cannot have anything but a string in there, however it's not
> worth fighting for.
>
> Dave
>
> Dave Cramer
>
> dave.cramer(at)credativ(dot)ca
> http://www.credativ.ca
>
>
> On Mon, Jan 28, 2013 at 4:03 PM, dmp <danap@ttc-cmc.net
> <mailto:danap@ttc-cmc.net>> wrote:
>
>     I think that is what threw me. You are still going to need to
>     have Nathaniel's patch in case someone does try to throw in a bogus
>     properties that ends up null even thought the url is correct.
>
>     danap.
>
>
>     Kevin Grittner wrote:
>
>         Dave Cramer<pg@fastcrypt.com <mailto:pg@fastcrypt.com>>  wrote:
>
>             My proposed patch is this
>
>
>             if (url.startsWith("jdbc:__postgresql:")) {
>                    return null;
>             }
>
>             Right at the top of getConnection, before we do any real work.
>
>
>             Thoughts ?
>
>
>         Shouldn't that have a bang to reverse the logic?
>
>         -Kevin
> -
>     Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org
>     <mailto:pgsql-jdbc@postgresql.org>)
>     To make changes to your subscription:
>     http://www.postgresql.org/__mailpref/pgsql-jdbc
>     <http://www.postgresql.org/mailpref/pgsql-jdbc>
>
>

Dave,

That looks about right. Nathaniel could you please review to confirm
that this is what you are expecting/advocating.

https://github.com/pgjdbc/pgjdbc/pull/37/files

danap.

Dave Cramer wrote:
> Ok, I've got a pending pull request if others could verify it, I'd
> appreciated it.
>
> Dave
>
> Dave Cramer
>
> dave.cramer(at)credativ(dot)ca
> http://www.credativ.ca