PG Bug reporting form <noreply@postgresql.org> writes:
> The following script:
> CREATE TABLE t(a int, b varchar);
> CREATE FUNCTION f(i int) RETURNS text LANGUAGE SQL
> RETURN (SELECT b FROM t WHERE a = $1);
> ALTER TABLE t ALTER COLUMN b TYPE text;
> fails with:
> ERROR: unexpected object depending on column: function f(integer)
> on REL_14_STABLE .. master since e717a9a18.
Thanks for the report. It looks like most of the other hard cases
in RememberAllDependentForRebuilding just error out with code
along the lines of
ereport(ERROR,
(errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
errmsg("cannot alter type of a column used by a view or rule"),
I'm inclined to do likewise for functions. We could imagine trying
to re-parse the function definition against the new column type,
but there are way too many ways for that to go wrong. Just for
starters, there are possibly-security-grade hazards if the current
search_path isn't what it was when the function was created. There's
no guarantee that we'd succeed anyway, eg the new column type might
not work for some function or operator that's applied to it, and if
not the resulting error message would likely be very surprising.
regards, tom lane