> david.g.johnston@gmail.com wrote:
>
>> bryn@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
variableare used in expressions or statements, the data types of the fields must not change from one call of the
functionto the next, since each expression will be analyzed using the data type that is present when the expression is
firstreached.
>
> 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'dbe overly worried about. Actually making DDL changes of this nature should be rare if not forbidden. Once live
on-the-flycolumn type changes just shouldn't happen so having a plan in place that accommodates them is adding cost for
noreal 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-sessionsbefore doing such a DDL and re-start them only when all such DDLs are done successfully.