| 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
| 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 |