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

(RMT hat on, unless otherwise noted)

On 9/20/22 9:42 AM, Robert Haas wrote:
> On Mon, Sep 19, 2022 at 11:03 PM Jonathan S. Katz <jkatz(at)postgresql(dot)org> wrote:
>> For #1 (allowing calls that have schema/table overlap...), there appears
>> to be both a patch that allows this (reversing[8]), and a suggestion for
>> dealing with a corner-case that is reasonable, i.e. disallowing adding
>> schemas to a publication when specifying column-lists. Do we think we
>> can have consensus on this prior to the RC1 freeze?
>
> I am not sure whether we can or should rush a fix in that fast, but I
> agree with this direction.

The RMT met today to discuss this.

We did agree that the above is an open item that should be resolved
before this release. While it is an accepted pattern for us to "ERROR"
on unsupported behavior and then later introduce said behavior, we do
agree with Peter's original post in this thread and would like it resolved.

As for the state of the fix, the patch has been iterated on and Amit
felt ready to commit it[1]. We do want to hear how others feel about
this, but the folks behind this feature have been working on this patch
since this was reported.

>> For #2 ("ALL TABLES IN SCHEMA" syntax), this was heavily discussed on
>> the original thread[1][3][4][5][7]. I thought Tom's proposal on the
>> syntax[3] was reasonable as it "future proofs" for when we allow other
>> schema-scoped objects to be published and give control over which ones
>> can be published.
>
> All right, well, I still don't like it and think it's confusing, but
> perhaps I'm in the minority.

The RMT discussed this as well. The RMT feels that there should not be
any changes to syntax/behavior for this release. This doesn't preclude
future work in this area (e.g. having a toggle for "all future
behavior"), but based on all the discussions and existing behavior in
this feature, we do not see a need to make changes or delay the release
on this.

>> I don't think we should change this behavior that's already in logical
>> replication. While I understand the reasons why "GRANT ... ALL TABLES IN
>> SCHEMA" has a different behavior (i.e. it's not applied to future
>> objects) and do not advocate to change it, I have personally been
>> affected where I thought a permission would be applied to all future
>> objects, only to discover otherwise. I believe it's more intuitive to
>> think that "ALL" applies to "everything, always."
>
> Nah, there's room for multiple behaviors here. It's reasonable to want
> to add all the tables currently in the schema to a publication (or
> grant permissions on them) and it's reasonable to want to include all
> current and future tables in the schema in a publication (or grant
> permissions on them) too. The reason I don't like the ALL TABLES IN
> SCHEMA syntax is that it sounds like the former, but actually is the
> latter. Based on your link to the email from Tom, I understand now the
> reason why it's like that, but it's still counterintuitive to me.

<PersonalOpinion>
I understand your view on "multiple behaviors" and I do agree with your
reasoning. I still think we should leave this as is, but perhaps this
opens up an option we add later to specify the behavior.
</PersonalOpinion>

>
>> For #3 (more superuser-only), in general I do agree that we shouldn't be
>> adding more of these. However, we have in this release, and not just to
>> this feature. ALTER SUBSCRIPTION ... SKIP[11] requires superuser. I
>> think it's easier for us to "relax" privileges (e.g. w/predefined roles)
>> than to make something "superuser-only" in the future, so I don't see
>> this being a blocker for v15. The feature will continue to work for
>> users even if we remove "superuser-only" in the future.
>
> Yeah, this is clearly not a release blocker, I think.

The RMT concurs. We do recommend future work on "relaxing" the
superuser-only requirement.

Thanks,

Jonathan

[1]
https://www.postgresql.org/message-id/CAA4eK1LDhoBM8K5uVme8PZ%2BkxNOfVpRh%3DoO42JtFdqBgBuj1bA%40mail.gmail.com