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
