Re: search_path improvements

Поиск
Список
Период
Сортировка
От Sam Mason
Тема Re: search_path improvements
Дата
Msg-id 20090601192717.GP5407@samason.me.uk
обсуждение исходный текст
Ответ на Re: search_path improvements  (Greg Stark <stark@enterprisedb.com>)
Ответы Re: search_path improvements  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
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".

--  Sam  http://samason.me.uk/
[1] http://archives.postgresql.org/message-id/5A1FE6B1-9857-454C-A385-BA061DED346F@kineticode.com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_standby -l might destory the archived file
Следующее
От: Robert Haas
Дата:
Сообщение: Re: It's June 1; do you know where your release is?