From: | Richard Troy <rtroy(at)ScienceTools(dot)com> |
---|---|
To: | Oliver Jowett <oliver(at)opencloud(dot)com> |
Cc: | <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: driver initialization and connection separation |
Date: | 2010-01-31 05:38:08 |
Message-ID: | Pine.LNX.4.33.1001302136100.6187-100000@denzel.in |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
On Sat, 30 Jan 2010, Richard Troy wrote:
>
> jdbc:postgresql://%h:%p/%d
> jdbc:postgresql://%h:%p/%d?%o
> jdbc:postgresql://%h:%p/%d?user=%u&password=%pw
> jdbc:postgresql://%h:%p/%d?user=%u&password=%pw&%o
>
> where %h is the host
> %p is the port
> %u is the username
> %pw is the password
> and %o is the optional keyword=value[&keyword=value] string.
>
> ...I think what's happening is that the value that gets substituted for %o
> isn't being cleared when it evaluates the new connection data; if there
> was no "optional" information to add to the URL for the new connection,
> it's retaining its old value. This would explain what I saw and not be an
> issue with Postgres at all, obviously!
>
> I've got some work to do to prove the point, and I've got the flu, so I'll
> probably leave it until tomorrow. However, it fits the observed
> behavior... I should have proved the point before opening my big yap! I'll
> blame that social gaff on the flu! -wink-
>
...That was it alright: our code wasn't clearing the options - which in
this case included:
ssl=true&sslfactory=org.postgresql.ssl.NonValidatingFactory
Sorry to have troubled anyone,
Richard
From | Date | Subject | |
---|---|---|---|
Next Message | Nedim Cholich | 2010-02-01 18:53:37 | Jdbc4ResultSet getClob and getBlob are calling getLong internally |
Previous Message | Richard Troy | 2010-01-31 03:49:27 | Re: driver initialization and connection separation |