Re: So, are we going to bump catversion for beta5, or not? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: So, are we going to bump catversion for beta5, or not?
Date
Msg-id 10867.1066829322@sss.pgh.pa.us
Whole thread Raw
In response to Re: So, are we going to bump catversion for beta5, or not?  (Richard Huxton <dev@archonet.com>)
Responses Re: So, are we going to bump catversion for beta5, or not?
Re: So, are we going to bump catversion for beta5, or not?
Re: So, are we going to bump catversion for beta5, or not?
List 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 by date:

Previous
From: Rod Taylor
Date:
Subject: Re: integer ceiling in LIMIT and OFFSET
Next
From: Tom Lane
Date:
Subject: Re: integer ceiling in LIMIT and OFFSET