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 1944626.1714572523@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>)
Responses Re: BUG #18449: Altering column type fails when an SQL routine depends on the column
Re: BUG #18449: Altering column type fails when an SQL routine depends on the column
List pgsql-bugs
Alexander Lakhin <exclusion@gmail.com> writes:
> 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

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.

            regards, tom lane



pgsql-bugs by date:

Previous
From: Alexander Lakhin
Date:
Subject: Re: BUG #18449: Altering column type fails when an SQL routine depends on the column
Next
From: "David G. Johnston"
Date:
Subject: Re: BUG #18451: NULL fails to coerce to string when performing string comparison