On 27 October 2015 at 21:19, rajan <vgmon...@gmail.com> wrote: > Hey Craig, > > 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. Here's some code that filters allowable commands. It doesn't care which user id is used, but it's pretty simple to add a check to only run the filter when a particular user ID is the active user. This won't do what you want, but serves as a rough example of how you can filter statements based on the parsed statement data: https://github.com/2ndQuadrant/bdr/blob/bdr-plugin/next/bdr_commandfilter.c and also: http://www.postgresql.org/docs/current/static/xfunc-c.html http://www.postgresql.org/docs/current/static/extend-extensions.html http://www.postgresql.org/docs/current/static/extend-pgxs.html Note that BDR's command filter doesn't do anything to insert/update/delete/select. For that you'd *also* need an ExecutorStart_hook or similar. 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? -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers