Re: BUG #18449: Altering column type fails when an SQL routine depends on the column - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #18449: Altering column type fails when an SQL routine depends on the column
Date
Msg-id 2292717.1714684570@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #18449: Altering column type fails when an SQL routine depends on the column  (Alexander Lakhin <exclusion@gmail.com>)
List pgsql-bugs
Alexander Lakhin <exclusion@gmail.com> writes:
> 01.05.2024 17:08, Tom Lane wrote:
>> It doesn't seem too awful to me to write the errmsg as
>> errmsg("cannot alter type of a column used in a %s",
>>        get_object_class_descr(foundObject.classId)),

> I agree, though by doing that we'll loose the ability to detect obviously
> wrong dependencies, say, when a role depends on a table column (if
> INTERNAL_ERRORs expected to be handled as something abnormal),
> but ATExecAlterColumnType() is hardly an appropriate place for such
> detection anyway. So I would sacrifice this ability to make this function
> simpler now and in the future.

I tried that, and it fell over on your example:

regression=# ALTER TABLE t ALTER COLUMN a TYPE bigint;
ERROR:  unrecognized class ID: 6106

6106 is pg_publication_rel, and apparently get_object_class_descr's
ambitions don't go far enough to include that.  Perhaps that should
be fixed, because if we have dependencies with that classId then
eventually somebody is going to wish to print debugging messages about
them.  However, that's probably not a project to undertake right now
with a release deadline looming.  For today, I'll just do something
exactly like 42b041243, except for publications.

            regards, tom lane



pgsql-bugs by date:

Previous
From: Alena Rybakina
Date:
Subject: Re: BUG #17257: (auto)vacuum hangs within lazy_scan_prune()
Next
From: Thomas Munro
Date:
Subject: Re: Windows Application Issues | PostgreSQL | REF # 48475607