Don Baccus <dhogaza@pacifier.com> writes:
> At 12:30 PM 5/30/01 -0400, Tom Lane wrote:
> >Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >> I think the major problem was that our pg_proc table doesn't have any
> >> way of handling arg changes. In fact, we need a ALTER FUNCTION
> >> capability first so we can recreate functions in place with the same
> >> OID.
> >
> >Actually that's the least of the issues. The real problem is that
> >because of function overloading, myfunc(int4) and myfunc(int2) (for
> >example) are considered completely different functions. It is thus
> >not at all clear what should happen if I create myfunc(foo.f1%TYPE)
> >and later alter the type of foo.f1 from int4 to int2. Does myfunc(int4)
> >stop existing?
>
> What happens now with PL/pgSQL variables? Does it continue to point
> int4 as long as the backend stays alive, but switch in new backends
> as they come to life, the function gets called, and the body recompiled?
>
> (Compiled bytes are stored on a per-backend basis, right? Or wrong? :)
>
> That's not particularly relevant to the parameter case other than to
> point out that we may already have some weirdness in PL/pgSQL in
> this regard.
I assume you mean: what happens now with a PL/pgSQL variable which is
declared using table.row%TYPE?
As you suspect, the answer is that any existing backend which has
already compiled the function will continue to use the old
definition. Any new backend will recompile the function and get the
new definition.
As far as I can see in a quick look, there is currently no interface
to direct PL/pgSQL that it must reparse a function. And there is no
way for PL/pgSQL to register interest in table changes.
Ian
