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