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?
|
Список | 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 по дате отправления: