Re: Comments on adding more connection URL parameters.

[Barry Lind <blind(at)xythos(dot)com>]

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