Re: why can't a table be part of the same publication as its schema - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: why can't a table be part of the same publication as its schema
Date
Msg-id E95013AD-9690-466D-9B5A-A3221DA425E4@enterprisedb.com
Whole thread Raw
In response to Re: why can't a table be part of the same publication as its schema  ("Jonathan S. Katz" <jkatz@postgresql.org>)
Responses Re: why can't a table be part of the same publication as its schema
List pgsql-hackers

> On Sep 19, 2022, at 8:03 PM, Jonathan S. Katz <jkatz@postgresql.org> wrote:
>
> "When a partitioned table is added to a publication, all of its existing and future partitions are implicitly
consideredto be part of the publication."[10] 
>
> Additionally, this is the behavior that is already present in "FOR ALL TABLES":
>
> "Marks the publication as one that replicates changes for all tables in the database, including tables created in the
future."[10]
>
> I don't think we should change this behavior that's already in logical replication.

The existing behavior in logical replication doesn't have any "IN SCHEMA" qualifiers.

> While I understand the reasons why "GRANT ... ALL TABLES IN SCHEMA" has a different behavior (i.e. it's not applied
tofuture objects) and do not advocate to change it, I have personally been affected where I thought a permission would
beapplied to all future objects, only to discover otherwise. I believe it's more intuitive to think that "ALL" applies
to"everything, always." 

The conversation is focusing on what "ALL TABLES" means, but the ambiguous part is what "IN SCHEMA" means.  In GRANT it
means"currently in schema, computed now."  We are about to create confusion by adding the "IN SCHEMA" phrase to
publicationcommands meaning "later in schema, computed then."  A user who diligently consults the documentation for one
commandto discover what "IN SCHEMA" means may fairly, but wrongly, assume it means the same thing in another command. 

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






pgsql-hackers by date:

Previous
From: torikoshia
Date:
Subject: Re: RFC: Logging plan of the running query
Next
From: Ajin Cherian
Date:
Subject: Re: Support logical replication of DDLs