| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
| Cc: | bt22nakamorit <bt22nakamorit(at)oss(dot)nttdata(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Fix error message for MERGE foreign tables |
| Date: | 2022-10-14 08:35:53 |
| Message-ID: | Y0kfaULckKj+AR4E@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Oct 14, 2022 at 12:26:19PM +0800, Richard Guo wrote:
> Maybe something like below, so that we keep it consistent with the case
> of a foreign table being specified as a target.
>
> --- a/contrib/postgres_fdw/postgres_fdw.c
> +++ b/contrib/postgres_fdw/postgres_fdw.c
> @@ -1872,6 +1872,13 @@ postgresPlanForeignModify(PlannerInfo *root,
> returningList,
> &retrieved_attrs);
> break;
> + case CMD_MERGE:
> + ereport(ERROR,
> + (errcode(ERRCODE_FEATURE_NOT_SUPPORTED),
> + errmsg("cannot execute MERGE on relation \"%s\"",
> + RelationGetRelationName(rel)),
> +
> errdetail_relkind_not_supported(rel->rd_rel->relkind)));
> + break;
Yeah, you should not use an elog(ERROR) for cases that would be faced
directly by users.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bharath Rupireddy | 2022-10-14 08:45:19 | Re: thinko in basic_archive.c |
| Previous Message | Michael Paquier | 2022-10-14 08:33:14 | Re: Move backup-related code to xlogbackup.c/.h |