From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Sam Mason <sam(at)samason(dot)me(dot)uk> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: search_path improvements |
Date: | 2009-06-01 19:46:10 |
Message-ID: | 603c8f070906011246g66a994ear2be30a95d3200641@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 1, 2009 at 3:27 PM, Sam Mason <sam(at)samason(dot)me(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-06-01 19:51:23 | Re: It's June 1; do you know where your release is? |
Previous Message | Tom Lane | 2009-06-01 19:44:51 | Re: It's June 1; do you know where your release is? |