Re: BUG #18449: Altering column type fails when an SQL routine depends on the column
От | Tom Lane |
---|---|
Тема | Re: BUG #18449: Altering column type fails when an SQL routine depends on the column |
Дата | |
Msg-id | 2292717.1714684570@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #18449: Altering column type fails when an SQL routine depends on the column (Alexander Lakhin <exclusion@gmail.com>) |
Список | 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 по дате отправления: