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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alexander Lakhin <exclusion(at)gmail(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Subject: Re: BUG #18449: Altering column type fails when an SQL routine depends on the column
Date: 2024-05-02 21:16:10
Message-ID: 2292717.1714684570@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Alexander Lakhin <exclusion(at)gmail(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Thomas Munro 2024-05-02 23:50:58 Re: Windows Application Issues | PostgreSQL | REF # 48475607
Previous Message Alena Rybakina 2024-05-02 18:36:31 Re: BUG #17257: (auto)vacuum hangs within lazy_scan_prune()