Alessio Bragadini <alessio@albourne.com> writes:
> Tom Lane wrote:
>> But it's not really tracking the variable; with Ian's proposed
>> implementation, after
>>
>> create table foo(bar int4);
>>
>> create function fooey(foo.bar%type) ...;
>>
>> drop table foo;
>>
>> create table foo(bar int8);
>>
>> you would still have fooey declared as taking int4 not int8, because
>> the type meant by %type is resolved and frozen immediately upon being
>> seen.
> Ok, this is a more general point: in Oracle (which, as Ian points out,
> uses this feature extensively) if you recreate table foo, function fooey
> is tagged as 'dirty' and recompiled on the spot next time is used. This
> is also true for VIEWs and other objects, so you don't have the problem
> we have when a view breaks because you've updated the underlining table.
Indeed, and we have plans to do something similar sometime soon. My
real objection to this proposed feature is that there is no way to
handle the update as a local matter within the function, because
changing the function's input datatypes actually means it's a different
function. This creates all sorts of problems at both the definitional
and implementation levels...
regards, tom lane
