Re: Avoiding explicit addDataType calls for PostGIS

Kris Jurka

unread,

Nov 8, 2004, 3:37:17 AM11/8/04

to

> [use a property file to configure datatypes]
>

Looking at this patch again, I don't believe the JDBC driver should use
this extension mechanism to configure itself. The whole concept is error
prone with multiple .properties files, so why should we start things off
by creating a properties file when we don't need to.

Kris Jurka

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Oliver Jowett

unread,

Nov 8, 2004, 3:50:08 AM11/8/04

to

Kris Jurka wrote:
>
>>[use a property file to configure datatypes]
>
> Looking at this patch again, I don't believe the JDBC driver should use
> this extension mechanism to configure itself. The whole concept is error
> prone with multiple .properties files,

I don't see multiple properties files with overlapping settings being a
common use case for exactly that reason.

> so why should we start things off
> by creating a properties file when we don't need to.

The configuration information is bulky, so cramming it into the URL
doesn't seem ideal.

It's also cleaner from a packaging perspective: you don't need to poke
application-specific internal configuration information into a
user-visible or user-configured URL.

-O

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Kris Jurka

unread,

Nov 8, 2004, 4:02:36 AM11/8/04

to

On Mon, 8 Nov 2004, Oliver Jowett wrote:

> Kris Jurka wrote:
> >
> >>[use a property file to configure datatypes]
> >
> > Looking at this patch again, I don't believe the JDBC driver should use
> > this extension mechanism to configure itself. The whole concept is error
> > prone with multiple .properties files,
>
> I don't see multiple properties files with overlapping settings being a
> common use case for exactly that reason.
>
> > so why should we start things off
> > by creating a properties file when we don't need to.
>
> The configuration information is bulky, so cramming it into the URL
> doesn't seem ideal.
>
> It's also cleaner from a packaging perspective: you don't need to poke
> application-specific internal configuration information into a
> user-visible or user-configured URL.
>

Let me be more clear. I like the properties file method for configuring
external libraries (postgis), but I don't like it for configuring the
driver itself. Specifically consider your addition of prepareThreshold=5,
suppose I wanted to override this setting with my own properties file.
Then I'd have to be real careful about how I setup my classpath.

Kris Jurka

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majo...@postgresql.org

Oliver Jowett

unread,

Nov 8, 2004, 4:23:37 AM11/8/04

to

Kris Jurka wrote:

> Let me be more clear. I like the properties file method for configuring
> external libraries (postgis), but I don't like it for configuring the
> driver itself. Specifically consider your addition of prepareThreshold=5,
> suppose I wanted to override this setting with my own properties file.
> Then I'd have to be real careful about how I setup my classpath.

Ah, ok.

Currently, if someone wants to change a default, they have to either
modify the driver source and recompile, or remember to override the
built-in default in every single URL ever used.

If the default is stored in a properties file packaged with the driver,
they can tweak the default by editing that properties file, which seems
much easier.

I agree that trying to manage multiple properties files that override
each other is confusing, because it's so dependent on what the
classloader decides to do. So don't do that!

Kris Jurka

unread,

Nov 8, 2004, 4:54:39 AM11/8/04

to

On Mon, 8 Nov 2004, Oliver Jowett wrote:

> Kris Jurka wrote:
>
> > Let me be more clear. I like the properties file method for configuring
> > external libraries (postgis), but I don't like it for configuring the
> > driver itself. Specifically consider your addition of prepareThreshold=5,
> > suppose I wanted to override this setting with my own properties file.
> > Then I'd have to be real careful about how I setup my classpath.
>
> Ah, ok.
>
> Currently, if someone wants to change a default, they have to either
> modify the driver source and recompile, or remember to override the
> built-in default in every single URL ever used.
>
> If the default is stored in a properties file packaged with the driver,
> they can tweak the default by editing that properties file, which seems
> much easier.

We're getting closer to understanding each other. I've just committed
a version of this patch that reads all available
org.postgresql.driverconfig.properties files and uses them to set any
defaults. My whole point is that I did not want to put a
driverconfig.properties file in postgresql.jar because we don't need to
and it will only create potential problems.

Kris Jurka

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Markus Schaber

unread,

Nov 9, 2004, 11:49:00 AM11/9/04

to

Hi, Kris,

On Mon, 8 Nov 2004 04:54:39 -0500 (EST)
Kris Jurka <bo...@ejurka.com> wrote:

> We're getting closer to understanding each other. I've just committed
> a version of this patch that reads all available
> org.postgresql.driverconfig.properties files and uses them to set any
> defaults. My whole point is that I did not want to put a
> driverconfig.properties file in postgresql.jar because we don't need to
> and it will only create potential problems.

So we continue to have the defaults compiled in, instead of delivering
them with a properties file, but parse third-party property files.

I thing that's a good decision, I think.

Thanks a lot,
Markus