Re: Comments on adding more connection URL parameters.

Kris,

I also have a few more,

one to change the behaviour for handling booleans, from inserting 't',
'f' to inserting '1', and '0'

I think one way to deal with this on a non-connection basis is to use
System properties, this won't work for the schema search path, but would
work for most others.

How do the other drivers handle this?

Dave
On Tue, 2004-02-03 at 03:57, 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
>
--
Dave Cramer
519 939 0336
ICQ # 14675561