Re: Skipping schema changes in publication

From: Dilip Kumar <dilipbalaut(at)gmail(dot)com>
To: shveta malik <shveta(dot)malik(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, YeXiu <1518981153(at)qq(dot)com>, Ian Lawrence Barwick <barwick(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Skipping schema changes in publication
Date: 2026-01-21 07:21:15
Message-ID: CAFiTN-vMpoX=TnxZq2_CmAH_k_DnJLp1Tu7-YT+uWvNGoPzfxg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 21, 2026 at 12:03 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> On Fri, Jan 16, 2026 at 4:59 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Tue, Jan 6, 2026 at 6:13 PM Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com> wrote:
> > >
> > > Also addressed the remaining comments. I have also addressed the
> > > comments by Peter in [1]. I have also done some minor cosmetic
> > > changes.
> > >
> >
> > CREATE PUBLICATION pub1 FOR ALL TABLES EXCEPT TABLE (t1,t2);
> >
> > Did we consider using EXCLUDE instead of EXCEPT? In another similar
> > feature being discussed, the community is proposing to use EXCLUDE to
> > SQL Standard, so won't it be better to use EXCLUDE here as well?
> >
> > [1] - https://www.postgresql.org/message-id/63e1587b-4258-41de-b823-948f8cc692d9%40eisentraut.org
> >
>
> I am listing all current usages of EXCEPT and EXCLUDE to decide us better:
>
> EXCEPT:
> 1. Set Operator (EXCEPT / EXCEPT ALL) (docs at [1])
>
> Syntax: query1 EXCEPT [ALL] query2.
>
> EXCEPT returns all rows that are in the result of query1 but not in
> the result of query2.
>
> Example: SELECT id, name FROM employees EXCEPT SELECT id, name FROM contractors;
>
>
> 2. IMPORT FOREIGN SCHEMA … EXCEPT (docs at [2])
>
> Syntax:
> IMPORT FOREIGN SCHEMA remote_schema
> [ { LIMIT TO | EXCEPT } ( table_list ) ]
> FROM SERVER server_name INTO local_schema
> [ OPTIONS (...) ];
>
> LIMIT TO (table_list) → import only the listed tables.
> EXCEPT (table_list) → import all tables except the listed ones.
>
> Example:
> IMPORT FOREIGN SCHEMA public EXCEPT (audit_log)
> FROM SERVER remote_pg INTO remote_import;
>
> ~~
>
> EXCLUDE:
> 1. Exclusion Constraints (docs at [3])
> Syntax:
> CREATE TABLE table_name
> ( column_name data_type,
> EXCLUDE USING index_method ( column_name WITH operator [, ...] ) );
>
> Prevents rows from violating a condition defined by operators.
>
> Example:
> CREATE TABLE circles ( c circle, EXCLUDE USING gist (c WITH &&) );
> Or
> CREATE TABLE foo (x int, EXCLUDE (x WITH =)); --This is essentially
> like a UNIQUE constraint but defined via EXCLUDE.
>
> 2.
> In Window Function Calls (docs at [4])
> We use EXCLUDE in the window frame exclusion clause.
> In SQL, when we use OVER (...) with ROWS or RANGE, we can also specify
> EXCLUDE to control which rows are considered in the window frame.
>
> Options explained:
> EXCLUDE CURRENT ROW → exclude the current row from the frame.
> EXCLUDE GROUP → excludes the current row and its ordering peers from the frame.
> EXCLUDE TIES → excludes any peers of the current row from the frame,
> but not the current row itself
> EXCLUDE NO OTHERS → include everything (default).
>
> Example:
> SELECT id, value, SUM(value)
> OVER ( ORDER BY id ROWS
> BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
> EXCLUDE CURRENT ROW )
> AS running_sum_excluding_current FROM test;
>
> ~~
>
> IMO, we use EXCEPT in postgres when we want to filter a set of objects
> from all selected objects and we use EXCLUDE mostly in terms of rows
> based constraints/exclusion.
>
> And our example of :
> Create publication pub1 for all tables EXCEPT/EXCLUDE tab1,tab2;
>
> has more resemblance to:
>
> IMPORT FOREIGN SCHEMA public EXCEPT (audit_log) FROM SERVER remote_pg
> INTO remote_import;
>
> So based on above, +1 for EXCEPT for our case.

I agree based on existing examples EXCEPT seems more relevant for our
use case. So +1 for EXCEPT.

--
Regards,
Dilip Kumar
Google

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message jian he 2026-01-21 07:37:00 Re: Change COPY ... ON_ERROR ignore to ON_ERROR ignore_row
Previous Message John Naylor 2026-01-21 07:13:59 Re: Update some comments for fasthash