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

From: "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>
To: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Subject: Re: why can't a table be part of the same publication as its schema
Date: 2022-09-21 02:16:07
Message-ID: 40e5b4b1-e3ac-b771-e7e2-009483cbf970@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

[personal views, not RMT]

On 9/20/22 4:06 PM, Mark Dilger wrote:

> I don't complain that it is buidling on the existing behavior. I'm *only* concerned about the keywords we're using for this. Consider the following:
>
> -- AS ADMIN
> CREATE USER bob NOSUPERUSER;
> GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA foo TO bob;
> SET ROLE bob;
> CREATE PUBLICATION bobs_pub FOR ALL TABLES IN SCHEMA foo;
>
> We're going to have that fail in pg15 because the FOR ALL TABLES IN SCHEMA option is reserved to superusers. But we agreed that was a stop-gap solution that we'd potentially loosen in the future. Certainly we'll need wiggle room in the syntax to perform that loosening:
>
> --- Must be superuser for this in pg15, and in subsequent releases.
> CREATE PUBLICATION bobs_pub FOR ALL FUTURE TABLES IN SCHEMA foo;
>
> --- Not supported in pg15, but reserved for some future pg versions to allow
> --- non-superusers to create publications on tables currently in schema foo,
> --- assuming they have sufficient privileges on those tables
> CREATE PUBLICATION bobs_pub FOR ALL TABLES IN SCHEMA foo;
>
> Doing it this way makes the syntax consistent between the GRANT...TO bob and the CREATE PUBLICATION bobs_pub. Surely this makes more sense?

When you put it that way, I see your point. However, for the
lesser-privileged user though, will the behavior be that it will
continue to add all future tables in a schema to the publication so long
as they have sufficient privileges on those tables? Or would that mirror
the current behavior with GRANT?

While I understand it makes it consistent, the one concern I raise is
that it means the less privileged user could have a less convenient user
experience than the privileged user. Perhaps that's OK, but worth noting.

> I'm not a huge fan of the keyword "FUTURE" here, but I found a reference to another database that uses that keyword for what I think is a similar purpose.

I did try doing research on this prior, but hadn't thought to
incorporate "future" into my searches.

Doing so, I probably found the same database that you did that used the
"FUTURE" word for adding permissions to future objects (and this is
fresh, as the docs for it were published last week). That's definitely
interesting.

I did see some notes on a legacy database system that offered similar
advice to what we do for GRANT if you're not using ALTER DEFAULT PRIVILEGES.

> We should choose *something* for this, though, if we want things to be rational going forward.

That all said, while I understand your point and open to the suggestion
on "FUTURE", I'm not convinced on the syntax change. But I'll sleep on it.

Jonathan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message kuroda.hayato@fujitsu.com 2022-09-21 02:21:37 RE: [PATCH] Use indexes on the subscriber when REPLICA IDENTITY is full on the publisher
Previous Message wangw.fnst@fujitsu.com 2022-09-21 02:14:35 RE: Perform streaming logical transactions by background workers and parallel apply