Re: So, are we going to bump catversion for beta5, or not?

Поиск
Список
Период
Сортировка
От scott.marlowe
Тема Re: So, are we going to bump catversion for beta5, or not?
Дата
Msg-id Pine.LNX.4.33.0310221312260.12830-100000@css120.ihs.com
обсуждение исходный текст
Ответ на Re: So, are we going to bump catversion for beta5, or not?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: So, are we going to bump catversion for beta5, or not?  (Richard Huxton <dev@archonet.com>)
Список pgsql-hackers
On Wed, 22 Oct 2003, Tom Lane wrote:

> Richard Huxton <dev@archonet.com> writes:
> > On Wednesday 22 October 2003 06:55, Peter Eisentraut wrote:
> >> The idea is that you give each function its own schema search path at
> >> creation time, and that path applies to that function for the rest of its
> >> life.  Then that function would be immune to schema path changes later on.
> 
> > But surely that would mean I couldn't do ...
> 
> Certainly you can invent scenarios where letting the search path vary
> from call to call is useful, but the question is which behavior is
> *more* useful.  I think it's becoming clear that having a predictable
> search path is usually what a function author will want.
> 
> It would probably be a good idea to allow the function's search path to
> be explicitly specified as a clause of CREATE FUNCTION (otherwise it
> will be a headache for pg_dump).  So we could allow both viewpoints,
> if there is a way to explicitly say "don't force any search path".
> Perhaps specifying an empty path could mean that.  But I think the
> default should be to adopt the current search path (at the time of
> CREATE FUNCTION) as the function's permanent path.

It might be nice to have an alter function capability that could change 
the search path at a later date should one add schema etc... later on.



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

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: is GiST still alive?
Следующее
От: Christopher Browne
Дата:
Сообщение: Re: is GiST still alive?