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
