Re: Comments on adding more connection URL parameters.

Kris,

I have no problem with having a larger number of parameters, although we
should look carefully at how many we add. So for me the issue isn't how
many or what types, but how are they set.

I think the process of setting them via the jdbc url is only suitable
for a limited number of parameters, since urls are often typed in by
hand into many applications you can't have 50 parameters also needed on
the url.

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)

Once the number of parameters becomes larger, I would expect most people
will end up using property files for their parameters and then change
individual ones on a case by case basis via the url or jvm for exception
cases.

thanks,
--Barry

Kris Jurka wrote:

> I am aware of at least three feature proposals that have adding a
> parameter to the connection URL as a requirement. I would like to solicit
> comments on a policy for adding new URL parameters. Is there are reason
> to try and restrict the number of supported parameters? Proposals right
> now include a login timeout, a server side prepared statement threshold
> where server statements are used after a certain number of uses, and a
> schema search path setting. These three proposals accurately reflect the
> range of possible reasons for neeeding a parameter:
>
>
> http://archives.postgresql.org/pgsql-jdbc/2004-01/msg00106.php
> login timeout: This is the only possible way to support this feature.
> This information must be available before the connection is created, so
> the URL is the only reasonable place to put it.
>
> http://archives.postgresql.org/pgsql-jdbc/2003-12/msg00019.php
> server prepare threshold: This makes using server prepared statements
> possible without using pg specific code. It also allows server side
> prepares to automatically turn themselves on for reused statements which
> is the exact situation that this is desireable. It is possible to
> implement this feature entirely in client code, but it would be a real
> mess.
>
> http://gborg.postgresql.org/project/pgjdbc/bugs/bugupdate.php?668
> schema search path: This allows setting a GUC parameter "search_path" on
> a per connection basis. This is only useful in the situation where it
> cannot be handled by the per user or per database defaults. This is
> something which can be handled entirely in client code by issuing an
> appropriate SET command, but would arguably be cleaner in the URL,
> especially in a connection pooling situation. The problem is that once
> you add any GUC variable you don't have a strong basis for not adding them
> all. I could see using guc_ as a prefix and any parameter starting that
> way we tried to issue a SET on.
>
> So I'd like your thoughts on adding new parameters. Only things not
> possible without them? Only significant improvements that would be real
> difficult without them? Only certain GUC variables? All GUC variables?
>
>
> Kris Jurka
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match