On Tue, Mar 7, 2023 at 1:24 PM Bryn Llewellyn <bryn@xxxxxxxxxxxx> 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 it (variable declarations):is 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.
David J.
