From: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: why can't a table be part of the same publication as its schema |
Date: | 2022-09-11 17:07:49 |
Message-ID: | 917B3A3D-AEA5-4613-88D8-08155DA28CB5@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Sep 10, 2022, at 4:17 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
>>> I don't understand why we
>>> used this ALL TABLES IN SCHEMA language.
>>
>> The conversation, as I recall, was that "ADD SCHEMA foo" would only mean all tables in foo, until publication of other object types became supported, at which point "ADD SCHEMA foo" would suddenly mean more than it did before. People might find that surprising, so the "ALL TABLES IN" was intended to future-proof against surprising behavioral changes.
>
> If I encountered this syntax in a vacuum, that's not what I would
> think. I would think that ADD ALL TABLES IN SCHEMA meant add all the
> tables in the schema to the publication one by one as individual
> objects
Yes, it appears the syntax was chosen to avoid one kind of confusion, but created another kind. Per the docs on this feature:
FOR ALL TABLES IN SCHEMA
Marks the publication as one that replicates changes for all tables in the specified list of schemas, including tables created in the future.
Like you, I wouldn't expect that definition, given the behavior of GRANT with respect to the same grammatical construction.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-09-11 17:52:55 | Re: Splitting up guc.c |
Previous Message | Tom Lane | 2022-09-11 14:53:22 | Re: [PATCH] initdb: do not exit after warn_on_mount_point |