Re: Distinguish publication exclusions in object addresses

From: shveta malik <shveta(dot)malik(at)gmail(dot)com>
To: Peter Smith <smithpb2250(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, shveta malik <shveta(dot)malik(at)gmail(dot)com>
Subject: Re: Distinguish publication exclusions in object addresses
Date: 2026-09-16 08:21:37
Message-ID: CAJpy0uCp+43rgbPE9v8Zy0FXq=nssizOsbaF0NNaezTK65XVYQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 16, 2026 at 12:46 PM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
>
> On Wed, Sep 16, 2026 at 3:51 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > > 4.
> > > + if (isexcept)
> > > + ereport(ERROR,
> > > + (errcode(ERRCODE_WRONG_OBJECT_TYPE),
> > > + errmsg("\"%s\" is not a published relation of publication \"%s\"",
> > > + RelationGetRelationName(relation), pubname)));
> > > + else
> > > + ereport(ERROR,
> > > + (errcode(ERRCODE_WRONG_OBJECT_TYPE),
> > > + errmsg("\"%s\" is not an excluded relation of publication \"%s\"",
> > > + RelationGetRelationName(relation), pubname)));
> > >
> > > Publications can have the same table name in multiple schemas. The
> > > name should be fully-qualified in the errmsg to eliminate any
> > > ambiguity.
> > >
> >
> > But I don't see any ambiguity here as the user can only pass one
> > relation name. Also, we use the unqualified name in nearby message
> > [1]. We use RelationGetRelationName all over the code in the error
> > messages and I don't see the need to qualify here. We will simply
> > return the name the user has passed.
> >
>
> In this experiment below I got an unexpected result.
> - Is it a bug?
> - Is it somehow reporting about a "t1" table of another schema?
> - Did I type something wrong somewhere?
>
> I cannot tell because the table name was not qualified...
>
> CREATE SCHEMA s1;
> CREATE SCHEMA s2;
> CREATE SCHEMA s3;
>
> CREATE TABLE t1(a int);
> CREATE TABLE s1.t1(a int);
> CREATE TABLE s2.t1(a int);
> CREATE TABLE s3.t1(a int);
>
> CREATE PUBLICATION pub FOR ALL TABLES EXCEPT (TABLE s2.t1, s3.t1);
>
> SELECT pg_get_object_address('publication relation','{public,t1}','{pub}');
> 2026-09-16 17:06:17.136 AEST [250078] ERROR: publication relation
> "t1" in publication "pub" does not exist
> 2026-09-16 17:06:17.136 AEST [250078] STATEMENT: SELECT
> pg_get_object_address('publication relation','{public,t1}','{pub}');
> ERROR: publication relation "t1" in publication "pub" does not exist
>
> That message can't be right because....
>
> \d+ public.t1
> Table "public.t1"
> Column | Type | Collation | Nullable | Default | Storage |
> Compression | Stats target | Description
> --------+---------+-----------+----------+---------+---------+-------------+--------------+-------------
> a | integer | | | | plain |
> | |
> Included in publications:
> "pub"
> Access method: heap
>

I had encountered this while testing version 1 posted by Fujii-san in
this thread. It behaves the same not only for ALL TABLES publications,
but also for TABLES IN SCHEMA publications. Perhaps the idea here is
to give object-address of pg_publication_rel catalog and not combined.
This is what I understood at that time. But I couldn't find any doc
describing this behavior. Perhaps the docs need to be updated to
clarify this on HEAD. We can discuss this in a separate thread.

thanks
Shveta

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2026-09-16 08:22:44 Re: Use C11 alignas instead of palloc/malloc for alignment
Previous Message Zhijie Hou (Fujitsu) 2026-09-16 07:59:58 RE: Race conditions in logical decoding