At 12:48 PM 31/03/2008, Anderson Farias wrote:

>IMHO, the concept of ROLES *could* change to something more 'smart', a
>'server side only' feature, transparent for the client which whould'n have
>to know anything about it (like it's names). And users would have all it's
>granted rights without having to logoff/login (if I have the right, WHY
>should I have to do that?? There's no logic on that!)

Quite right, the way you think about the concept, it is lacking the logic to make it work for you.

>I'm not saying it's wrong, I understand how it works and IMO, it can (and
>should) be *enhanced* -- by the time it gets important enougth to get into
>FB development tight schedule already full of great and (probably) more
>important enhancements.

Altering the concept of SQL Privileges to make it work differently to the standard is a VERY UNLIKELY objective, even if there were nothing else to do. ;-) Like Doug, I think you really *still* don't understand how roles are intended to work. Those who do understand it do USE it because, used properly, it removes a lot of the messiness from SQL privileges and make the task of assigning and revoking the package of privileges to and from users very clean, quick and simple. It is NOT intended to be used in combination with a mish-mash of privileges granted and revoked/partly revoked to/from individual users or PUBLIC.

I've recently been troubleshooting a database where nobody had ever thought to use roles. They have 4,999 privileges assigned for 50 tables and 12 users, many of them conflicting and some for users no longer existing in the security database. In fact, all they needed was two roles consisting of 46 and 50 GRANTs respectively, for 8 current users. All that should ever be needed to keep that database ship-shape is to grant a role when the user joins and revoke it when s/he leaves.

./heLen