From: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(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 04:00:00 |
Message-ID: | 95a01e66-0c92-2ff6-b243-849ddd11685d@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
01.05.2024 17: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)),
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.
Best regards,
Alexander
From | Date | Subject | |
---|---|---|---|
Next Message | Kostiantyn Tomakh | 2024-05-02 06:56:13 | Re: BUG #18433: Logical replication timeout |
Previous Message | Bruce Momjian | 2024-05-01 18:21:06 | Re: BUG #18433: Logical replication timeout |