Re: Review items for EXCEPT TABLE publication

From: Peter Smith <smithpb2250(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: vignesh C <vignesh21(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Review items for EXCEPT TABLE publication
Date: 2026-09-11 08:27:28
Message-ID: CAHut+Ps9Hk7-50dER6mq+DahF+NVmNywLQKEHVT-bV-FhMFwXQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 11, 2026 at 6:03 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Fri, Sep 11, 2026 at 1:13 PM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
> >
> > On Fri, Sep 11, 2026 at 5:22 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > >
> > >
> > > Yes, but how does that matter? We just don't want the operation to
> > > proceed when the table is part of publication, users anyway need to
> > > fix it before proceeding.
> > >
> >
> > OTOH it doesn't matter because they are both problems the user must
> > fix. But won't it be better to get a consistent/deterministic error
> > message for the same problem?
> >
>
> Sure, but to distinguish ERROR-type, extra scan on catalog seems
> costly. If you can avoid extra scans and or more cycles on scanning
> catalog and still be able to manage this difference, then it is worth
> considering.
>

+ if (!toLogged)
+ {
+ bool isexcept;
+
+ if (RelationHasPublication(RelationGetRelid(rel), &isexcept))
+ {
+ if (isexcept)
+ ereport(ERROR,
+ (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
+ errmsg("cannot change table \"%s\" to unlogged because it is
referenced in a publication EXCEPT clause",
+ RelationGetRelationName(rel)),
+ errdetail("Unlogged relations cannot be specified in a publication
EXCEPT clause."),
+ errhint("Remove the table from the EXCEPT clause using ALTER
PUBLICATION ... SET ALL TABLES first.")));
+ else
+ ereport(ERROR,
+ (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
+ errmsg("cannot change table \"%s\" to unlogged because it is part of
a publication",
+ RelationGetRelationName(rel)),
+ errdetail("Unlogged relations cannot be replicated.")));
+ }
+ }

I don't really see what is gained by splitting those error messages,
since the user will get an indeterminate one, and either way they have
to fix it

IMO, a single unified message could be a simpler/better choice here:

e.g.

ereport(ERROR,
(errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
errmsg("cannot change table \"%s\" to unlogged because it is
referenced by a publication",
RelationGetRelationName(rel)),
errdetail("Unlogged relations cannot be published or excluded via
an EXCEPT clause."),
errhint("Remove the table from the publication first.")));

======
Kind Regards,
Peter Smith.
Fujitsu Australia

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Borodin 2026-09-11 08:33:33 Re: Race between prepared transaction commit and checkpointer
Previous Message Fujii Masao 2026-09-11 08:06:30 Re: pg_createsubscriber does not check output_plugin_libraries