Comments on adding more connection URL parameters.

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