Re: search_path vs extensions - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: search_path vs extensions
Date
Msg-id 4A1DA9F9.1020003@dunslane.net
Whole thread Raw
In response to Re: search_path vs extensions  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: search_path vs extensions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

Andrew Gierth wrote:
> Splitting up search_path is something I've been thinking about for a
> while (and threw out on IRC as a suggestion, which is where Dimitri
> got it); it was based on actual experience running an app that set the
> search path in the connection parameters in order to select which of
> several different schemas to use for part (not all) of the data.  When
> setting search_path this way, there is no way to set only part of it;
> the client-supplied value overrides everything.
>
> Obviously there are other possible solutions, but pretending there
> isn't a problem will get nowhere.
>
> (Setting the search path using a function or sql statement _after_
> connecting was not an option; it would have confused the connection
> persistance layer, which needed different parameters to tell the
> connections apart.)
>   


Another way of handling this might be to provide for prepending or 
appending to the search path (or even for removing items from it).

examples - something like:
   alter database foo set search_path = '+bar, baz'; -- append   alter database foo set search_path = 'bar, baz+'; --
prepend


cheers

andrew


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [PATCH] plpythonu datatype conversion improvements
Next
From: Tom Lane
Date:
Subject: Re: search_path vs extensions