Re: Support EXCEPT for TABLES IN SCHEMA publications

From: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Support EXCEPT for TABLES IN SCHEMA publications
Date: 2026-06-09 21:36:13
Message-ID: CAN4CZFOaHBAUUrHmcCayUHVzcSw+SjWPEDuWT-5ij-KgxUP5=g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> Do you mean other.t should be there?

Yes, that was a typo in my example.

> After considering, I chose to follow behavior similar to existing FOR
> ALL TABLES publications to handle schema-switch cases. Today, if a
> table excluded via EXCEPT is dropped, the corresponding prexcept entry
> is removed, and recreating a table with the same name does not
> automatically restore the exclusion.
>
> I applied the same principle to schema changes: once an excluded table
> moves out of the schema, the exclusion is removed.

I'm not that sure about the analogy. DROP TABLE is a destructive
operation, executing DROP TABLE and then CREATE TABLE won't
automatically bring back the data.

With this approach, two cheap ALTER TABLE ... SET SCHEMA statements
can clear an EXCEPT clause without the proper permissions.

But I'm not sure what's the best solution for this. The v11 approach
is at least more consistent than the previous behavior.

> 1) Reject the schema change: Error out if a table with a prexcept
> entry is moved between schemas. This feels overly restrictive.

It is restrictive, but maybe it's the better solution? Or
alternatively, maybe it should require proper permissions to remove
the except clause?

Another thing that could improve this if we would print out a warning
that the statement caused a change in the publication? But then that's
also a question for the preexisting drop table case.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2026-06-09 21:44:02 Re: libpq maligning postgres stability
Previous Message Sami Imseih 2026-06-09 21:31:21 Re: [PATCH v4] pg_stat_statements: Add last_execution_start column