Re: Support EXCEPT for TABLES IN SCHEMA publications

From: Peter Smith <smithpb2250(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: shveta malik <shveta(dot)malik(at)gmail(dot)com>, Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Support EXCEPT for TABLES IN SCHEMA publications
Date: 2026-04-15 02:05:31
Message-ID: CAHut+Pvj4=GWoJEd4EBdp4pi6KxXQ46ioW=PV+=UktiXr2gCvg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Apr 14, 2026 at 7:37 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Tue, Apr 14, 2026 at 2:05 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> >
> > On Tue, Apr 14, 2026 at 1:03 PM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
> > >
> > > On Tue, Apr 14, 2026 at 4:30 PM Nisha Moond <nisha(dot)moond412(at)gmail(dot)com> wrote:
> > > >
> > > > Hi hackers,
> > > >
> > > > Following earlier work to support EXCEPT for FOR ALL TABLES [1]
> > > > publications, starting this thread to extend the same capability to
> > > > schema-level publications (TABLES IN SCHEMA).
> > >
> > > Hi Nisha.
> > >
> > > +1 for adding this new kind of exclusion clause to CREATE PUBLICATION command.
> > >
> > > >
> > > > Currently, TABLES IN SCHEMA publishes all tables in a schema with no
> > > > way to exclude a subset. Users who want to skip a few tables must
> > > > switch to an explicit FOR TABLE list, which loses the convenience of
> > > > schema-level publishing and requires ongoing maintenance as tables are
> > > > added.
> > > >
> > > > Proposed syntax:
> > > > ------------------------
> > > > CREATE PUBLICATION pub FOR TABLES IN SCHEMA s1 EXCEPT (s1.t1, s1.t2);
> > > > ALTER PUBLICATION pub ADD TABLES IN SCHEMA s1 EXCEPT (s1.t1);
> > > > ALTER PUBLICATION pub SET TABLES IN SCHEMA s1 EXCEPT (s1.t1);
> > > >
> > > > Note: Tables in the EXCEPT clause must be schema-qualified to avoid
> > > > ambiguity and must belong to the published schema; otherwise, an error
> > > > is raised.
> > > >
> > >
> > > The proposed syntax is almost, but not quite, what I was anticipating.
> > > IMO the syntax shouldn't just be similar to the FOR ALL TABLES EXCEPT;
> > > It can be *identical* to it. e.g., your examples are missing the
> > > 'TABLE' keyword necessary to achieve the same command flexibility.
> > > Furthermore, what is the ambiguity referred to? An excluded table is
> > > clearly associated with the preceding schema. Can't the code infer the
> > > schema internally even when it is not provided by the user? Of course,
> > > the user *can* specify a schema-qualified name if they want to, but I
> > > didn't see why we are forcing that rule upon them.
> >
> > +1. I also feel specifying only the table name is clear enough. Or are
> > we referring to implementation complexity here?
> >
>
> I think it will add complexity. Consider an example:
> CREATE PUBLICATION pub FOR TABLES IN SCHEMA s1, s2, s3 EXCEPT (t1, t2);
>
> So, which schema's exclusion list will these tables should be
> considered for? Say, if table with name t1 is present in all schemas
> then shall we exclude from all schemas or just consider it excluded
> from the first one (s1)?
>

The exact pattern is already in common usage for row-filters and
column-lists, yet nobody is confused.

-- all these tables have the same column names
-- (analogous to multiple schemas having same table names)
CREATE TABLE t1(c1 int, c2 int);
CREATE TABLE t2(c1 int, c2 int);
CREATE TABLE t3(c1 int, c2 int);

-- all tables have a column c1
-- but this c1 means t3.c1 because the column-list is only for the adjacent t3.
CREATE PUBLICATION pub1 FOR TABLE t1, t2, t3 (c1);

-- all tables have a column c2
-- but this c2 means t3.c2 because the row-filter is only for the adjacent t3.
CREATE PUBLICATION pub2 FOR TABLE t1, t2, t3 WHERE (c2 > 99);

\dRp+
Publication pub1
Owner | All tables | All sequences | Inserts | Updates | Deletes |
Truncates | Generated columns | Via root | Description
----------+------------+---------------+---------+---------+---------+-----------+-------------------+----------+-------------
postgres | f | f | t | t | t |
t | none | f |
Tables:
"public.t1"
"public.t2"
"public.t3" (c1)

Publication pub2
Owner | All tables | All sequences | Inserts | Updates | Deletes |
Truncates | Generated columns | Via root | Description
----------+------------+---------------+---------+---------+---------+-----------+-------------------+----------+-------------
postgres | f | f | t | t | t |
t | none | f |
Tables:
"public.t1"
"public.t2"
"public.t3" WHERE (c2 > 99)

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Xiaopeng Wang 2026-04-15 02:07:51 Re: off-by-one in pg_repack index loop
Previous Message Bruce Momjian 2026-04-15 01:53:50 Re: First draft of PG 19 release notes