On Mon, Aug 30, 2021 at 2:14 PM Greg Nancarrow <gregn4422@gmail.com> wrote:
>
> On Fri, Aug 27, 2021 at 4:13 PM vignesh C <vignesh21@gmail.com> wrote:
> >
> > I have implemented this in the 0003 patch, I have kept it separate to
> > reduce the testing effort and also it will be easier if someone
> > disagrees with the syntax. I will merge it to the main patch later
> > based on the feedback. Attached v22 patch has the changes for the
> > same.
>
> I notice that "CREATE PUBLICATION pub1 FOR ALL TABLES IN SCHEMA sc1,
> TABLE sc1.test;" maintains the table separately and results in the
> following in the \dRp+ output:
>
> Tables:
> "sc1.test"
> Schemas:
> "sc1"
>
> and also then "ALTER PUBLICATION pub1 DROP ALL TABLES IN SCHEMA sc1;"
> still leaves the "sc1.test" table in the publication.
I had intentionally implemented this way, the reason being it gives
the flexibility to modify the publications based on the way the
publication is created. My idea was that if a user specified a
table/schema of the same schema while creating the publication, the
user should be allowed to drop any of them at any time. In the above
case if we don't maintain the results separately, users will not be
able to drop the table from the publication at a later point of time.
Thoughts?
> Is there a reason why we don't/can't support "ALTER SUBSCRIPTION ...
> SET ALL TABLES;"?
> (I know it wasn't supported before, but now "ALTER SUBSCRIPTION ...
> SET ALL TABLES IN SCHEMA ..." is being supported)
I agree this can be implemented with the current design. I felt I can
work on getting the current patches into a committable shape and then
work on this after the current patch series is finished. Thoughts?
> I notice that the v22-0003 documentation updates for ALTER
> SUBSCRIPTION are missing - but you're probably waiting on all feedback
> before proceeding with that.
I have fixed this as part of v23 patch attached at [1].
[1] - https://www.postgresql.org/message-id/CALDaNm0xmqJeQEfV5Wnj2BawM%3DsdFdfOXz5N%2BgGG3WB6k9%3Dtdw%40mail.gmail.com
Regards,
Vignesh
