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

From Robert Haas
Subject Re: why can't a table be part of the same publication as its schema
Date
Msg-id CA+TgmoarPLLkyh8JbUVizjYdVkuvBCd7FsAY6CX1upvttPrybQ@mail.gmail.com
Whole thread Raw
In response to Re: why can't a table be part of the same publication as its schema  (Mark Dilger <mark.dilger@enterprisedb.com>)
Responses Re: why can't a table be part of the same publication as its schema
Re: why can't a table be part of the same publication as its schema
List pgsql-hackers
On Fri, Sep 9, 2022 at 2:17 PM Mark Dilger <mark.dilger@enterprisedb.com> wrote:
> > On Sep 9, 2022, at 8:18 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> > Things might be clearer if we'd made the syntax "ALTER PUBLICATION p1
> > { ADD | DROP } { TABLE | SCHEMA } name". 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
otherobject types became supported, at which point "ADD SCHEMA foo" would suddenly mean more than it did before.
Peoplemight 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, i.e. add the tables that are currently as of this moment in
that schema to the publication; and I would think that ADD SCHEMA
meant remember that this schema is part of the publication and so
whenever tables are created and dropped in that schema (or moved in
and out) what is being published is automatically updated.

The analogy here seems to be to GRANT, which actually does support
both syntaxes. And if I understand correctly, GRANT ON SCHEMA gives
privileges on the schema; whereas GRANT ON ALL TABLES IN SCHEMA
modifies each table that is currently in that schema (never mind what
happens later).

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Index ordering after IS NULL
Next
From: Michael Paquier
Date:
Subject: Re: Bump MIN_WINNT to 0x0600 (Vista) as minimal runtime in 16~