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

Поиск
Список
Период
Сортировка
От Robert Treat
Тема Re: So, are we going to bump catversion for beta5, or not?
Дата
Msg-id 1066831301.2063.8392.camel@camel
обсуждение исходный текст
Ответ на Re: So, are we going to bump catversion for beta5, or not?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, 2003-10-22 at 09:28, 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.
> 

Well, you certainly need a way to do both, since IMHO the most useful
would be to have the search path be equal to the callers search path, at
least in the case of SECURITY INVOKER. YMMV.

Robert Treat
-- 
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Timestamp docs weirdness
Следующее
От: "Marc G. Fournier"
Дата:
Сообщение: Last beta ... we hope?