Re: BUG #18449: Altering column type fails when an SQL routine depends on the column

Hello Tom,

28.04.2024 04:48, Tom Lane wrote:
> 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.

I've discovered one more case, presumably as hard as the other ones:
CREATE TABLE t(a int);
CREATE PUBLICATION p FOR TABLE t WHERE (a > 0);

ALTER TABLE t ALTER COLUMN a TYPE bigint;
fails with:
ERROR:  unexpected object depending on column: publication of table t in publication p

Reproduced on REL_15_STABLE (52e4f0cd4) .. master.

> 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.

It looks like all these considerations apply to expressions defining row
filters for publications...

Best regards,
Alexander