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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: So, are we going to bump catversion for beta5, or not?
Дата
Msg-id 10867.1066829322@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: So, are we going to bump catversion for beta5, or not?  (Richard Huxton <dev@archonet.com>)
Ответы Re: So, are we going to bump catversion for beta5, or not?  (Robert Treat <xzilla@users.sourceforge.net>)
Re: So, are we going to bump catversion for beta5, or not?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: So, are we going to bump catversion for beta5, or not?  ("scott.marlowe" <scott.marlowe@ihs.com>)
Список pgsql-hackers
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.
        regards, tom lane


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

Предыдущее
От: Rod Taylor
Дата:
Сообщение: Re: integer ceiling in LIMIT and OFFSET
Следующее
От: Tom Lane
Дата:
Сообщение: Re: integer ceiling in LIMIT and OFFSET