From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Richard Huxton <dev(at)archonet(dot)com> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: So, are we going to bump catversion for beta5, or not? |
Date: | 2003-10-22 13:28:42 |
Message-ID: | 10867.1066829322@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Richard Huxton <dev(at)archonet(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-10-22 13:44:30 | Re: integer ceiling in LIMIT and OFFSET |
Previous Message | Rod Taylor | 2003-10-22 12:34:56 | Re: integer ceiling in LIMIT and OFFSET |