Skip site navigation (1) Skip section navigation (2)

Re: Search path in connection string

From: "David Johnston" <polobo(at)yahoo(dot)com>
To: "'Julien Demoor'" <jdemoor(at)gmail(dot)com>, <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Search path in connection string
Date: 2012-07-31 00:41:17
Message-ID: 023a01cd6eb5$32a1e8a0$97e5b9e0$ (view raw, whole thread or download thread mbox)
Lists: pgsql-jdbc
From: pgsql-jdbc-owner(at)postgresql(dot)org [mailto:pgsql-jdbc-owner(at)postgresql(dot)org] On Behalf Of Julien Demoor
Sent: Monday, July 30, 2012 8:56 AM
To: pgsql-jdbc(at)postgresql(dot)org
Subject: [JDBC] Search path in connection string


There have been a number of messages on this list suggesting that the Postgres JDBC driver should support setting the search path as part of the connection string.


Can this be considered?


I have a use case where there doesn't appear to be any good alternatives: using BIRT, with multiple clients sharing a Postgres database with one schema each, one cannot just execute a SET SCHEMA statement (UPDATE pg_settings ... is not possible either) and qualifying object names is also not always possible (say, if there are stored procedures involved that use unqualified object names).


Besides being useful in this case and surely others, this feature makes sense: schemas can be used to offer separation of database objects very similar to that offered by having multiple databases, and the database itself is part of the connection string.


The patch proposed in is still applicable.






You can customize the connection string to accomplish this.  You vary the “user” that is connecting and configure a search_path specific to that user.


ALTER ROLE custom_role SET search_path = …


David J.


In response to


pgsql-jdbc by date

Next:From: Brady MathisDate: 2012-07-31 13:15:03
Subject: Re: Opening view that uses a function - empty column
Previous:From: David JohnstonDate: 2012-07-30 20:22:04
Subject: Re: Opening view that uses a function - empty column

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group