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 >
