Re: Distinguish publication exclusions in object addresses

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: vignesh C <vignesh21(at)gmail(dot)com>
Cc: shveta malik <shveta(dot)malik(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Distinguish publication exclusions in object addresses
Date: 2026-09-15 10:35:20
Message-ID: CAA4eK1+rjGQ2sstcaLs0B5-iKyxtBjFb4=cmYxVTBb-aYZokmg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 15, 2026 at 2:01 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
>
> The attached v2 version patch has the changes for the same. This also
> addresses Hou's comments from [1].
>

--- a/src/include/nodes/parsenodes.h
+++ b/src/include/nodes/parsenodes.h
@@ -2416,6 +2416,7 @@ typedef enum ObjectType
OBJECT_POLICY,
OBJECT_PROCEDURE,
OBJECT_PUBLICATION,
+ OBJECT_PUBLICATION_EXCLUDED_REL,

I was trying to evaluate whether the above change needs catversion
bump and reached conclusion that it doesn't need one because we never
store this enum on-disk as part of parse-trees. Do let me know if you
or others thinks differently.

*
static ObjectAddress
get_object_address_publication_rel(List *object,
- Relation *relp, bool missing_ok)
+ Relation *relp, bool missing_ok,
+ bool pubrel_is_exclusion)

It is better to use objtype here instead of boolean as we already use
at few other places.

*
+ if (!missing_ok)
+ {
+ if (pubrel_is_exclusion)
+ ereport(ERROR,
+ (errcode(ERRCODE_UNDEFINED_OBJECT),
+ errmsg("publication excluded relation \"%s\" from publication \"%s\"
does not exist",
+ RelationGetRelationName(relation), pubname)));
+ else
ereport(ERROR,
(errcode(ERRCODE_UNDEFINED_OBJECT),
errmsg("publication relation \"%s\" in publication \"%s\" does not exist",
RelationGetRelationName(relation), pubname)));

I think these messages are misleading because actually here the object
type is wrong rather than object doesn't exist.

Please find a top-patch for the above suggestions.

--
With Regards,
Amit Kapila.

Attachment Content-Type Size
v2-0001-amit.1.txt text/plain 8.3 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2026-09-15 10:36:40 Re: FOR PORTION OF code review
Previous Message Antonin Houska 2026-09-15 10:26:40 Re: REPACK (CONCURRENTLY) backend waits indefinitely when decoding worker fails to start