Re: why can't a table be part of the same publication as its schema
Jonathan S. Katz <jkatz@postgresql.org>
From: "Jonathan S. Katz" <jkatz@postgresql.org>
To: Mark Dilger <mark.dilger@enterprisedb.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
"houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>,
Amit Kapila <amit.kapila16@gmail.com>, vignesh C <vignesh21@gmail.com>,
Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers <pgsql-hackers@postgresql.org>,
Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Date: 2022-09-20T19:36:28Z
Lists: pgsql-hackers
On 9/20/22 10:55 AM, Mark Dilger wrote: > > >> 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 considered to 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. This behavior exists "FOR ALL TABLES" without the "IN SCHEMA" qualifier. This was discussed multiple times on the original thread[1]. > >> While I understand the reasons why "GRANT ... ALL TABLES IN SCHEMA" has a different behavior (i.e. it's not applied to future objects) and do not advocate to change it, I have personally been affected where I thought a permission would be applied 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 publication commands meaning "later in schema, computed then." A user who diligently consults the documentation for one command to discover what "IN SCHEMA" means may fairly, but wrongly, assume it means the same thing in another command. I tried to diligently read the sections where we talk about granting + privileges[2][3] to see what it says about "ALL * IN SCHEMA". Unless I missed it, and I read through it twice, it does not explicitly state whether or not "GRANT" applies to all objects at only that given moment, or to future objects of that type which are created in that schema. Maybe the behavior is implied or is part of the standard, but it's not currently documented. We do link to "ALTER DEFAULT PRIVILEGES" at the bottom of the GRANT[2] docs, but we don't give any indication as to why. (This is also to say we should document in GRANT that ALL * IN SCHEMA does not apply to future objects; if you need that behavior use ALTER DEFAULT PRIVILEGES. Separate thread :) I understand there is a risk of confusion of the similar grammar across commands, but the current command in logical replication has this is building on the existing behavior. Thanks, Jonathan [1] https://www.postgresql.org/message-id/flat/CALDaNm0OANxuJ6RXqwZsM1MSY4s19nuH3734j4a72etDwvBETQ%40mail.gmail.com [2] https://www.postgresql.org/docs/current/sql-grant.html [3] https://www.postgresql.org/docs/current/ddl-priv.html
Commits
-
Allow publications with schema and table of the same schema.
- 13a185f54ba5 16.0 landed
- b7256753ec25 15.0 landed