From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: RLS open items are vague and unactionable |
Date: | 2015-09-11 15:39:24 |
Message-ID: | CA+Tgmob6WzxtfpCT89YxpHzbfM3i4odae+ywjJaunPDd2gu26A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 11, 2015 at 9:48 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> The only reason to avoid providing that flexibility is the concern that
> it might be misunderstood and users might misconfigure their system.
> Removing the flexibility to have per-command visibility policies and
> instead force a single visibility policy doesn't add any capabilities.
That seems like an extremely weak argument. If a feature can't be
used for anything useful, the fact that it doesn't actively interfere
with the use of other features that are useful is not a reason to keep
it. Clearly, something needs to be done about this. Saying, you can
restrict by something other than ALL but it adds no security and
serves no use cases is, frankly, a ridiculous position. Tom's
proposal downthread is a reasonable one, and I endorse it: there may
be other approaches as well. But regardless of the particular
approach, if we're going to have per-command policies, then you need
to do the work to make them useful.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2015-09-11 15:47:02 | Re: 9.3.9 and pg_multixact corruption |
Previous Message | Robert Haas | 2015-09-11 15:35:16 | Re: RLS open items are vague and unactionable |