Hello Kevin,

This may be a trivial thing.... But what do you mean by shops? I actually
can't get it.... :-)
On 27-Oct-2015 7:37 PM, "Kevin Grittner" <kgri...@ymail.com> wrote:

> On Tuesday, October 27, 2015 8:52 AM, Craig Ringer <cr...@2ndquadrant.com>
> wrote:
> > On 27 October 2015 at 21:19, rajan <vgmon...@gmail.com> wrote:
> >> Thanks for your response. Seems like the workaround is difficult.
> >>
> >> I am trying to understand
> >> "
> >> ExecutorStart_hook and ProcessUtility_hook
> > Doing what you want will require being willing to spend a fair bit of
> > time becoming familiar with PostgreSQL's innards, writing extensions,
> > etc. It's not a simple "download, compile, run" process. You will need
> > to be confident with C programming and reading source code.
> > If this is going way too deep, perhaps you should post to
> > pgsql-general with a description of the underlying problem you are
> > trying to solve, i.e. *why* you want to be able to have a superuser
> > who can alter users but can't select, etc. What's the problem you're
> > trying to solve with this?
> This is a question I have seen before, as well as slight variations
> on it related to transaction isolation level.  Right now you can
> implement a read-only user by granting only SELECT rights to tables
> and also by setting the default_transaction_read_only = on.  The
> problem is that the latter is essentially just a suggestion, not an
> order.  I actually don't think it's as big a problem with read-only
> users, since that can still be accomplished (with enough work) by
> using the GRANT/REVOKE commands.  (Think how much faster and easier
> it could be if there is a role that allows the appropriate set of
> SELECTs but also allows some DML -- just set a read-only rule for
> the user and the existing role could work.)
> It is more problematic where a shop wants to use serializable
> transactions to ensure data integrity.  The only way to prevent
> someone from subverting the business rules is to code a lot of
> triggers on a lot of objects that throw an error if the isolation
> level is wrong.  It would be a boon to big shops if they could
> declare (preferably with the option to set it at a role level) that
> specific default_transaction_* settings could not be overridden.
> --
> Kevin Grittner
> EDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company

Reply via email to