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

On 01.05.24 16:08, Tom Lane wrote:
> Hm.  We could fix this by introducing another single-purpose error
> report, but I'm starting to think that that's failing to learn from
> experience.  Who's to say that other column dependencies aren't
> possible, now or in the future?  The only thing stopping us from
> treating the default: case as a normal ERRCODE_FEATURE_NOT_SUPPORTED
> error is that it might be hard to phrase the error message in a nice
> way.  We already have a precedent for this being an acceptable
> errdetail:
> 
>                      ereport(ERROR,
>                              (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
>                               errmsg("cannot alter type of a column used in a policy definition"),
>                               errdetail("%s depends on column \"%s\"",
>                                         getObjectDescription(&foundObject, false),
>                                         colName)));
> 
> 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)),
> 
> This'd fall foul of English a/an grammar rules for some object class
> names, so maybe we should phrase it a bit differently; but I'm sure
> translated messages commit worse grammar violations all the time.

Maybe something like

errmsg: cannot alter type of column %s because other objects depend on it

and then have the errdetails constructed similar to drop cascade.