On Tue, 12 Oct 2004, Oliver Jowett wrote:
> > That is a nice idea that allows to control default configuration without
> > recompiling, and without explicit code in the app.
> Here is a first cut at implementing this.
This generally looks good, but I was hoping Markus would do some of the
serious testing to see if it meets the needs of his real world app.
Particularly the question about the order the property files are found and
processed in. Additionally the claim that two applications running on the
same JVM want to use two different mappings, I'm not sure that's possible.
Some simpler questions I had are:
1) Is the name postgresql.properties with no package name a good idea? It
doesn't seem ideal for an application to have to create an org/postgresql
directory just to hold a properties file, but I don't like the idea of
invading a global namespace.
2) I notice you've set the default prepareThreshold to five as we agreed
to a while ago, but I haven't gotten around to doing. The reason I
haven't done it yet is because I was concerned about how to do this (and
keep it in sync) for the DataSource implementations. With this patch it
is impossible to set the prepareThreshold back to zero from the
DataSource. It would be a simple fix to change the DataSource code to
make this work, but since we're discussing the general ability to set
defaults I thought I'd bring it up.
In response to
pgsql-jdbc by date
|Next:||From: Slobodan Milosevics||Date: 2004-10-19 09:11:27|
|Subject: Encoding porblem in JDBC|
|Previous:||From: Tomas||Date: 2004-10-19 06:53:52|
|Subject: Re: NullPointerException in ResultSetMetaData getColumnCount|
pgsql-general by date
|Next:||From: Sim Zacks||Date: 2004-10-19 06:58:39|
|Subject: plpython question|
|Previous:||From: Tom Lane||Date: 2004-10-19 06:33:08|
|Subject: Re: Numeric user names |