Re: search_path improvements WAS: search_path vs extensions - Mailing list pgsql-hackers

From David E. Wheeler
Subject Re: search_path improvements WAS: search_path vs extensions
Date
Msg-id 5A1FE6B1-9857-454C-A385-BA061DED346F@kineticode.com
Whole thread Raw
In response to Re: search_path improvements WAS: search_path vs extensions  (Greg Stark <stark@enterprisedb.com>)
List pgsql-hackers
On May 29, 2009, at 5:16 PM, Greg Stark wrote:

> On Fri, May 29, 2009 at 11:03 PM, David E. Wheeler <david@kineticode.com 
> > wrote:
>> On May 29, 2009, at 2:52 PM, Josh Berkus wrote:
>>
>>> a) the ability to "push" a schema onto the current search path
>>> b) the ability to "pull" a schema off the current search path
>>
>> push, pop, shift, unshift. :-)
>>
>> Come to think of it, I want these for arrays, too. ;-)
>
> push and unshift sure -- and you do have those for arrays, it's  
> spelled ||.

Well, no, not quite, as push, pop, shift, and unshift change arrays in  
place, whereas || (and array_concat() and array_append() and  
array_prepend()) create and return a new array.

> I'm not so sure about pop/shift though. How would you know the element
> you want is at the beginning/end unless you just put it there?

Well, for arrays, I might use them in a function just as I currently  
use them for various things in Perl. For search_path, yeah, I'd use  
them for lexical scoping: unshift a path onto the search path at the  
beginning of the function and shift it off at the end. Or push it onto  
the end of the search path and pop it off at the end.

> I think what you really want is to use SET LOCAL or RESET to restore
> it to whatever it was before you started futzing with it. We might
> need a more flexible way to do that that isn't tied to transactions
> though.

Well, lexical scoping for the changes would help, for sure. And I  
think that RESET is fine, but it would be more useful to have ways to  
push and unshift, or even to splice (sometimes I might want to remove  
a schema from the search path no matter where it appears in the path).

Best,

David



pgsql-hackers by date:

Previous
From: Sushant Sinha
Date:
Subject: dot to be considered as a word delimiter?
Next
From: Bruce Momjian
Date:
Subject: Re: pg_migrator and an 8.3-compatible tsvector data type