(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 <jk...@postgresql.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
OpenPGP_signature
Description: OpenPGP digital signature
