Re: Re: Outstanding patches
От | Tom Lane |
---|---|
Тема | Re: Re: Outstanding patches |
Дата | |
Msg-id | 20670.989420803@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Outstanding patches (Alessio Bragadini <alessio@albourne.com>) |
Ответы |
Re: Re: Outstanding patches
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: