Re: search_path improvements
От | Robert Haas |
---|---|
Тема | Re: search_path improvements |
Дата | |
Msg-id | 603c8f070906011246g66a994ear2be30a95d3200641@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: search_path improvements (Sam Mason <sam@samason.me.uk>) |
Список | pgsql-hackers |
On Mon, Jun 1, 2009 at 3:27 PM, Sam Mason <sam@samason.me.uk> wrote: > On Mon, Jun 01, 2009 at 08:05:33PM +0100, Greg Stark wrote: >> As I said earlier I doubt "pop" or "delete" is ever going to actually >> be what you want. I suspect you're far more likely to want to restore >> it to what it was before you started altering it. >> >> As support I'll point out this is what our C api has. There's no short >> cut to strip out a single element of the path but the normal calling >> pattern is to set aside a copy of the old path, add modify it in some >> way -- often adding a schema to the head -- then restore the old path. > > Without reading much of what's been said here (I've read maybe ten of > the posts in this thread) I'll say it sounds a lot like lexical closures > are needed. Code is free to define and use generally use whatever is > in their closure, but can't affect what's outside it unless explicitly > granted. > > I saw these mentioned in another post by David Wheeler[1] but my client > says it wasn't directly responded to. He calls it "lexical scoping" > but I think closing over the environment seems more suitable---mainly > because it'll "go wrong" less often in the presence of functions defined > as "security definer". +1. ...Robert
В списке pgsql-hackers по дате отправления: