On Sat, 10 Sept 2022 at 07:32, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Fri, Sep 9, 2022 at 8:48 PM Robert Haas <robertmhaas@gmail.com> wrote:
> >
> > On Fri, Sep 9, 2022 at 10:29 AM houzj.fnst@fujitsu.com
> > <houzj.fnst@fujitsu.com> wrote:
> > > IIRC, the feature currently works almost the same as you described. It doesn't
> > > create entry for tables that are published via its schema level, it only record
> > > the published schema and check which tables are part of it.
> >
> > Oh, well if that's the case, that is great news.
> >
>
> Yes, the feature works as you and Hou-San have mentioned.
>
> > But then I don't
> > understand Amit's comment from before:
> >
> > > Yes, because otherwise, there was confusion while dropping the objects
> > > from publication. Consider in the above case, if we would have allowed
> > > it and then the user performs ALTER PUBLICATION p1 DROP ALL TABLES IN
> > > SCHEMA s1, then (a) shall we remove both schema s1 and a table that is
> > > separately added (s1.t1) from that schema, or (b) just remove schema
> > > s1?
> >
> > I believe that (b) is the correct behavior, so I assumed that this
> > issue must be some difficulty in implementing it, like a funny catalog
> > representation.
> >
>
> No, it was because of syntax. IIRC, during development, Greg Nancarrow
> raised a point [1] that a user can expect the individually added
> tables for a schema which is also part of the publication to also get
> dropped when she specifies DROP ALL TABLES IN SCHEMA. IIRC,
> originally, the patch had a behavior (b) but then changed due to
> discussion around this point. But now that it seems you and others
> don't feel that was right, we can change back to (b) as I think that
> shouldn't be difficult to achieve.
I have made the changes to allow creation of publication with a schema
and table of the same schema. The attached patch has the changes for
the same.
I'm planning to review and test the patch further.
Regards,
Vignesh
