Re: why can't a table be part of the same publication as its schema

On Fri, Sep 9, 2022 at 8:48 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Fri, Sep 9, 2022 at 10:29 AM houzj(dot)fnst(at)fujitsu(dot)com
> <houzj(dot)fnst(at)fujitsu(dot)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.

> 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.
>

It was exactly due to the reason Mark had mentioned in the email [2].

[1] - https://www.postgresql.org/message-id/CAJcOf-fTRZ3HiA5xU0-O-PT390A7wuUUkjP8uX3aQJLBsJNVmw%40mail.gmail.com
[2] - https://www.postgresql.org/message-id/596EA671-66DF-4285-8560-0270DC062353%40enterprisedb.com

--
With Regards,
Amit Kapila.