Re: ALTER TABLE ALTER CONSTRAINT misleading error message

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: jian he <jian(dot)universality(at)gmail(dot)com>
Cc: Álvaro Herrera <alvherre(at)kurilemu(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: ALTER TABLE ALTER CONSTRAINT misleading error message
Date: 2025-06-27 06:11:41
Message-ID: 16fa808d-c67e-46e5-ac44-ac19b5d33209@oss.nttdata.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2025/06/18 1:00, Fujii Masao wrote:
> I had overlooked that commands other than ALTER TABLE can also trigger
> this error. So mentioning just ALTER TABLE ... might be a bit misleading.
> Would it be better to use a message like
> "ALTER action ALTER CONSTRAINT ... NOT VALID is not supported",
> similar to what we already do in tablecmd.c?

I had this concern because other commands, like ALTER SEQUENCE ALTER CONSTRAINT NOT VALID,
can also hit this error, and seeing an error message that starts with ALTER TABLE ...
in that context can be confusing. That's why I thought a message like:

ERROR: ALTER action ALTER CONSTRAINT ... NOT VALID is not supported

would be clearer.

However, most ALTER ... commands (other than ALTER TABLE) don't support ALTER CONSTRAINT
at all, not just the NOT VALID clause. So in those cases, I think we should use
the existing error handling for other commands and emit an error like:

ERROR: ALTER action ALTER CONSTRAINT cannot be performed on relation ...

Only in the case of ALTER TABLE should we produce a more specific message, like:

ERROR: ALTER TABLE ... ALTER CONSTRAINT ... NOT VALID is not supported

To make this distinction, I just started thinking it's better to raise the error
in ATExecAlterConstraint() rather than in gram.y. I've attached a draft patch that
follows this approach.

Regards,

--
Fujii Masao
NTT DATA Japan Corporation

Attachment Content-Type Size
v3-0001-Fix-error-handling-of-ALTER-CONSTRAINT-NOT-VALID.patch text/plain 4.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yugo Nagata 2025-06-27 06:17:11 Re: Suggestion to add --continue-client-on-abort option to pgbench
Previous Message Fujii Masao 2025-06-27 05:34:35 Re: pg_restore --no-policies should not restore policies' comment