Barry Lind wrote:
> So I beleive that there needs to be some sort of hierarchy of locations
> where parameter values can be set. I would suggest something like the
> following:
>
> 1) jvm parameters (i.e. -Dxxx=yyy)
> 2) URL
> 3) property file specified by a url parameter
> 4) property file bundled in the jar (i.e.
> org/postgresql/conf.properties) - this allows application builders who
> bundle the jdbc driver with their application to set the parameters
> their application requires
> 5) property file in a default location (like user.home)
It seems that 1, 4, and 5 address the same problem (providing
system-wide defaults). Pick one?
DriverManager.getConnection() has a variant that takes a Properties
object, so I'd expect apps to support reading properties from a
configuration file to pass to the driver. Maybe it'd be preferable to
encourage apps to take this route rather than having a huge URL string.
I'm not sure we need to support passing a properties file location in
the URL (3) if we do this.
Another piece of this puzzle is the DataSource implementation. Currently
you can't get access to some of the parameters available via a URL if
using a DataSource: the DataSource implementation is responsible for
constructing the URL used from the current object state, but it only
includes server, port, and database (and passes username/password
directly). I'd like to see all properties accessible via DriverManager
also accessible via our DataSource implementation.
One issue with the DataSource mapping is that it gets harder to support
a whole family of parameters (e.g. the guc_ prefix suggested) in one go,
as we need to know the exact set of parameters we support at compile
time so we can declare the necessary accessor methods. Maybe we could
provide a catchall accessor (setExtraParameters()?) that takes a
Properties object or similar.
-O