| From: | Antonin Houska <ah(at)cybertec(dot)at> |
|---|---|
| To: | "Euler Taveira" <euler(at)eulerto(dot)com> |
| Cc: | "Amit Kapila" <amit(dot)kapila16(at)gmail(dot)com>, "Peter Eisentraut" <peter(dot)eisentraut(at)enterprisedb(dot)com>, "PostgreSQL Hackers" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Privileges on PUBLICATION |
| Date: | 2022-05-18 09:44:57 |
| Message-ID: | 57022.1652867097@antos |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Euler Taveira <euler(at)eulerto(dot)com> wrote:
> On Fri, May 13, 2022, at 3:36 AM, Antonin Houska wrote:
>
> Attached is my proposal. It tries to be more specific and does not mention the
> absence of the privileges explicitly.
>
> You explained the current issue but say nothing about the limitation. This
> information will trigger a question possibly in one of the MLs. IMO if you say
> something like the sentence above at the end, it will make it clear why that
> setup expose all data (there is no access control to publications) and
> explicitly say there is a TODO here.
>
> Additional privileges might be added to control access to table data in a
> future version of <productname>PostgreSQL</productname>.
I thought it sound too negative if absence of some feature was mentioned
explicitly. However it makes sense to be clear from technical point of view.
> I also wouldn't use the warning tag because it fits in the same category as the
> other restrictions listed in the page.
ok, please see the next version.
--
Antonin Houska
Web: https://www.cybertec-postgresql.com
| Attachment | Content-Type | Size |
|---|---|---|
| publication_filtering_warning_v2.diff | text/x-diff | 1.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2022-05-18 10:52:22 | Re: Handle infinite recursion in logical replication setup |
| Previous Message | Michael Paquier | 2022-05-18 09:20:08 | Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set |