Re: CREATE RULE problem/question requesting workaround
От | Chris Travers |
---|---|
Тема | Re: CREATE RULE problem/question requesting workaround |
Дата | |
Msg-id | 1070813106.4455.81.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: CREATE RULE problem/question requesting workaround (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: CREATE RULE problem/question requesting workaround
|
Список | pgsql-general |
On Mon, 2003-12-08 at 00:46, Tom Lane wrote: > Chris Travers <chris@travelamericas.com> writes: > > Is there any way to try to enforce a rewrite > > rule in such a away as to do the select query as normal, but if > > necessary raise an exception (to abort the select)? > > No. > > You need to rethink your permissions design. One idea that you *can* > make work is to have a view that everyone can read, but are only able to > see selected rows in. pg_stats works that way, and I think there are > examples in the information schema as well. > Not that this will help me at the moment, but any plans to remove the requirement that SELECT rules be unconditional, and use DO INSTEAD? I can see where lifting this restriction could cause some headaches for those implementing these sorts of rules (infinite recursion, etc), but it would be really nice to have for these types of circumstances (restricting the tables that must allow everyone read access to 2 or so). The way I would like to this implemented would be: 1) For all rules but DO INSTEAD on a select statement, the query results are discarded. This could allow utility functions to be "triggered" by select statements. 2) A different option would be to allow statement-level triggers for select queries. (We don't need tuple-level triggers, which would probably be overkill). The reason I am trying to do this is because I am trying to create a simple, lightweight layer to port a program designed for dedicated hosting (and database permissions) into a shared hosting environment. I can get all permissions to be enforced aside from select permissions. Adding every table as a view is not going to be likely to be feasible since it will involve a major maintenance nightmare. Depending on requirements, we may look at allowing most of the database to be readable to all users, but this is not ideal and I am looking for maintainable workarounds. I do thank you for your suggestion and we may use it for one or 2 tables. Best Wishes, Chris Travers
В списке pgsql-general по дате отправления: