> david.g.johns...@gmail.com wrote: > >> b...@yugabyte.com wrote: >> >> create table s.t(k serial primary key, v text); >> create function s.f(k_in in int) >> select s.f(1); > > text, function is now compiled with that type resolution fixed. > I think mostly attributable to: > > > The mutable nature of record variables presents another problem in this > > connection. When fields of a record variable are used in expressions or > > statements, the data types of the fields must not change from one call of > > the function to the next, since each expression will be analyzed using the > > data type that is present when the expression is first reached. > > Though possibly… variable declarations [are] considered structural: > > > The instruction tree fully translates the PL/pgSQL statement structure, > >> drop table s.t cascade; >> create table s.t(k serial primary key, v varchar(10)); >> select s.f(1); > > still text as the compiled artifact is re-executed > >> \c d0 d0$u0 >> select s.f(1); > > now varchar as the function is recompiled during its first use in this > session. > > Restarting everything is an approach to dealing with uncertainty. This > particular use case, though, isn't one that I'd be overly worried about. > Actually making DDL changes of this nature should be rare if not forbidden. > Once live on-the-fly column type changes just shouldn't happen so having a > plan in place that accommodates them is adding cost for no real benefit.
Thanks. I believe that you and I agree on the proper practice, paraphrased here slightly w.r.t. what I wrote in my point #6 in my email that started this thread: Regard a DDL on any object that an application uses as unsafe while the app is in use. You must terminate all client-sessions before doing such a DDL and re-start them only when all such DDLs are done successfully.
